| [Temporality] Temporality design [message #612951] |
Fri, 21 December 2007 14:05 |
 Jean-Claude Cote
Messages: 56
Registered: July 2009 |
Member |
|
|
Eike wrote:
Technical comment:
By forcing model developers to subclass a framework type (Temporality) your
framework becomes invasive to the model. This might not be desirable for all
models/model developers. With my CDO framework I started the model
integration the same way (model invasive) and all users came quickly back
with the question if there was a way to be more transparent. If you are
interested in the solution I found for this problem we can discuss that
(preferringly on the newsgroup). May be we are able to factor out a common
framework to integrate orthogonal functions ionto EMF models.
Conceptual comment/question:
How do you plan to handle object graphs (as opposed to single instances and
their attributes)? I guess your Temporality class will offer API to query
object state of other versions of that object. Does this API return this
object state as instances of EObject? If so, what will access to the
reference features deliver? In other words, will it be possible to navigate
a whole object graph like it had been at any time since creation of that
graph? Or will it only be possible to query old attribute values?
Eike,
I would like to discuss your solution to removing the invasive (Temporal
base class). I used this approach to leverage EMFs persistence. Since the
base class is modeled all of the versions get persisted for free.
So the whole design rests on a modeled Temporal base class and an
intercepting time aware EStore.
The time (version) aware EStore retrieves the attribute or reference value
according to the time obtained from the TimeProvider. So when you crawl a
graph are referenced EObjects the references are the ones for a given time.
That is you crawl the graph as it looked at a given time.
Thanks
jc
|
|
|
Powered by
FUDForum. Page generated in 0.05225 seconds
] 
Search
Help
Register
Login
Home
