Community
Participate
Working Groups
When CDOResource from a view/transaction is loaded or saved (only transactions), the time stamp must be set.
See also: bug #248296: Manage the "isLoaded" property of CDOResource
We should reset the timestamp when - load/loadTransition = current. - invalidate = URIConverter.NULL_TIME_STAMP - save/commit = current. Others suggestions ?
(In reply to comment #2) First I thought the timestamp should reflect the time of last modification (which might also be interesting), but the JavaDoc is clear: Returns the cached value of the time stamp when this resource was last loaded or saved, or NULL_TIME_STAMP if the resource is not loaded and the time stamp has not been set. The return value is represented as the number of milliseconds since the epoch (00:00:00 GMT, January 1, 1970). The returned value may not be the same as the actual time stamp if the resource has been modified via external means since the last load or save. --- > We should reset the timestamp when > - load/loadTransition = current. Yes. > - invalidate = URIConverter.NULL_TIME_STAMP Should we use isLoaded()? > - save/commit = current. Yes. More questions: - Should the time be local time or repository time? - Should the timestamp be updated on load of any contained object or only the resource object itself?
Adolfo, there are some semantic gaps between loading a file based resource and loading a CDOResource. The latter happens asynchronously and partially. This seems to require a re-interpretation of the original semantics of the time stamp. Could you please describe exactly what you need this value for, so that we can consider it?
(In reply to comment #4) > Adolfo, there are some semantic gaps between loading a file based resource and > loading a CDOResource. The latter happens asynchronously and partially. This > seems to require a re-interpretation of the original semantics of the time > stamp. Could you please describe exactly what you need this value for, so that > we can consider it? > Hi Eikke, sorry for the delay... Well, my idea about taking advantage from time stamp was to know if an on-memory Resource is synchronized with its persistent state.... I'm not sure if this makes sense in CDO, since AFAIK a CDOResource should be always synchronized, I mean...If I'm working with a CDOResource and somebody changes the resource in the underlying DB, my on-memory CDOResource will be automatically updated (if the elements changed in the DB were previously loaded in the CDOResource) I would like to know if my Resource is synchronyzed independently it's a CDOResource or "normal" Resource, in this case using the time-stamp. However I understand that the time stamp for a CDOResource is much more difficult to manage. I haven't thought about other advantages regarding the usage of the time stamp, or if it's worth trying to implement a mechanism for CDOResources,... For me, It would avoid me to distingish between a Resource and CDOResource to know if a Resource is synchronized... I hope the info helps... Cheers, Adolfo.
Is this feature still needed ? Is it for GMF ? Or something else ?
(In reply to comment #6) > Is this feature still needed ? > > Is it for GMF ? Or something else ? > Any effort to allow a CDO Resource to be treated as it were a Resource, it is worth for the project. The time stamp is a feature of a Resource, therefore, it would be interesting for clients if they had the possiblity of using it when dealing with a CDO Resource. I remember talking with Victor about different ways to tackle the problem, like having a timestamp per object in the database, or modifying the timestamp of every resource of every view when a object is modified in the data base... I'll talk to Victor so he can make a deep insight on a possible solution. Cheers.
Rebasing all unresolved enhancement requests to 3.0
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
