[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  

NodeData  
@OneToMany  
History  
// 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  
http://lists.typo3.org/cgi-bin/mailman/listinfo/neos


More information about the Neos mailing list