[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