[Neos] FYI: Summary of todays "Technical Meeting"

Dominique Feyer dfeyer at ttree.ch
Tue Jul 15 20:49:43 CEST 2014

I think that for version we don’t need to reinvent the wheel ;) 

Having a proper event sourcing sound for me a lots more elegant and clean. Completely decoupled, and maybe with enough abstraction to use external event sourcing database like geteventstore.com per example.

ttree sàrl  
Dominique Feyer  
Rue du Valentin 34 et demi
CH - 1004 Lausanne
+41 21  312 36 35  
dfeyer at ttree.ch
ttree.ch - @ttreeagency - plan d’accès

Le 15 juillet 2014 à 19:59:07, Carsten Bleicker (carsten at bleicker.de) a écrit:

Reading this i have a different idea maybe.  
Why not directly adding a OneToMany instead of a  
simple DateTime property and attach. A modeling wich could later be used  
do act as a versioning info?  
so for example for the first approach it could be  

// Simple DateTime  
protected $dateTime  

// Bitmask (created = 0, editet = 1, published = 2)  
protected $type  

// account info  
protected $account  

// for later features to act as versioning info storage?  
protected $diff  

Maybe this could also be totaly decoupled from the nodedata mapping  
and fetched by a getter so the "versioning" table stays total decoupled?  
node->getVersioningFinfo() could invoke the versioningRepo?  

> == Created/modified dates for nodes ==  
> * Initiator(s): Aske Ertmann  
> === Background: ===  
> Currently there's no timestamps on nodes making it difficult to see when something was created  
> or last modified. As a simple solution introducing fields for the two dates that are set automatically would suffice. However there are some challenges when using dates set automatically.  
> === CONCLUSIONS ===  
> * Fields:  
> ** Modified Date  
> ** Creation Date  
> ** Published Date *NEW*  
> * Modification == Creation on node creation  
> * Published Date == NULL on node creation  
> * Should a modified date be updated when publishing a proxy node to live? → NO. but we should introduce an additional TimeStamp field for the publish date. Note: That means that a node can get an older modified TS when being published!  
> * Should creation date be transferred between workspaces? → YES. should be always transferred.  
> * Should existing nodes have default dates set to when applying the migration or set to NULL? → NULL values not allowed for creation & modification dates. → set to DEFAULT DATE.  
> * Should copied nodes get a new creation/modification date? → Yes.  
> * Field names? e.g. '''creationDate''', created, createdAt, modifiedAt, modificationDate, '''lastModificationDate''', lastModifiedDate, updatedAt  
> ** Asset has "lastModified", Account has "creationDate"  
> → creationDate  
> → lastModificationDate  
> → lastPublicationDate  
> → additionally (optional): rename “Asset::lastModified”  

Neos mailing list  
Neos at lists.typo3.org  

More information about the Neos mailing list