require 'sequel' module P4PhoenixServices # * :iid : primary key # * :id : String id # * :version : Integer # * :change : Integer class Project < Sequel::Model one_to_many :streams end # * :iid : Primary key # * :stream : Stream 'identifier' class Stream < Sequel::Model many_to_one :project one_to_many :paths end # :iid : Primary key # :path_type : String (path type) # :view_path : String (not null) # :depot_path : String (nullable) # :compare_path : String (not null) class Path < Sequel::Model many_to_one :stream end end
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#3 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
#2 | 13482 | tjuricek |
Fix issues with running the Phoenix test suite against basic CRUD operations. Does *not* test the notifications mechanism, but we have preliminary phoenix project caching on create, and does generate a simple stream for each phoenix project. |
||
#1 | 13472 | tjuricek |
Implementation of the phoenix services side of notification handling. This is just implementation and work-in-progress. Phoenix projects will now have paths cached in the phoenix services process, which we'll use to "guess" what file changes affect which Phoenix project. We basically see a changed path, then see that it might be relevant to one of the Phoenix project stream views, and then issue a "p4 changes -m1 //stream..." to see what the last change number is. If the change number goes up, we trigger an update. Note that how this all gets configured is with an account from notification services to phoenix services, which ideally is some kind of system account that sees all relevant files. Otherwise, you'll likely get changes filtered by protections, and thus, updates may not get sent out. |