Community
Participate
Working Groups
In the deltas or revision CDOIDExternal would need to be kept. if (id.isExternal()) { // return a string ((CDOIDExternal)id).getURI(); } When populates the CDORevision CDOIDUtil.createExternal(string); It is possible that id.isExternal() && id.isTemporary Usually this is because applyIDMapping wasn't called and/or the end-user didn't commit in the right order. GOing in a XATransaction will help
From a chat with Martin: for the dbstore i have a vague idea how to implement ext-refs dbstore's CDOIDs are long ints all positive (zero is null) we could introduce negative ids tha make the store look in a separate id -> uri table
another solution would be: just add a string column to all our references tables. but i'm not sure about the overhead
You mean a string containing an URL if the reference is external and NULL otherwise? A database implementation using VARCHAR as column type usually only uses those bytes which are required (+1). So a string column containing NULL should only take 1-2 bytes of additional storage per row. On the other hand, in bug 254567 we wanted to split up CDOIDs to (cdo_class_id, cdo_instance_id) anyway. So, defining a special cdo_class_id for external references would also be an option in that context ...
Hi Stefan, I would not directly use cdo_class_id for that. In the Teneo relational db the foreign key in the database does not require the cdo_class_id to be present as a column in the db. My reason for having a cdoid with both a classid and instance id is that the cdoid can be passed around in the server java code and be used to query the db (although I understand that the objectstore only needs the id). This week I added external reference support to Teneo standalone. With Teneo you can now tag an ereference with an @External annotation to specify that it should be stored as an external reference (a string/varchar) instead of a foreign key. I am not sure if it is useful for CDO stores in general, but maybe it is interesting: http://www.elver.org/hibernate/hibernate_relations.html#external gr. Martin
(In reply to comment #3) > You mean a string containing an URL if the reference is external and NULL > otherwise? Yes, for the case we "embed" the external refs into our existing reference tables (additionally). I forgot to mention that we'd need to do this with single-valued references as well! In the case that we choose the approach with a separate cdo_external_targets table, we'd need no NULL rows. > A database implementation using VARCHAR as column type usually only uses those > bytes which are required (+1). So a string column containing NULL should only > take 1-2 bytes of additional storage per row. Given that this could scale out badly in terms of size and that it clutters the schema it would be nice to make the approach extensible and configurable. What do you think? > On the other hand, in bug 254567 we wanted to split up CDOIDs to (cdo_class_id, > cdo_instance_id) anyway. So, defining a special cdo_class_id for external > references would also be an option in that context ... I don't think that this is a good idea because we'd need the concrete type of external target objects, too. Emf needs it to instantiate an appropriate proxy!
Created attachment 141446 [details] first implementation - incomplete This patch is an untested and a bit incomplete implementation of external reference support for the DB store. The final step of the implementation would require introducing an IDBStoreAccessor parameter in all of the TypeMappings. Since this will collide with the current effort in bug 282976, I will postpone this until the said bug is committed.
Created attachment 141519 [details] implementation finished - to be reviewed
Created attachment 141538 [details] Patch - to be committed Well done!
Thanks. Committed to HEAD.
Guys, has this been fixed to HEAD 3.0, right? If so, please tag accordingly. Is there any chance to fix it in 2.0? Cheers, Víctor.
Eike, the information on this bug is still wrong and misleading. This is the bug for 3.0. And this bug patch has been shipped in some 3.0 milestone, but we don't know which one :( I suspect this was an early bug fix in the 3.0 stream, so it has probably been included in M1.
External references are in 2.0 as fix of Bug 289237. This bug refers to 3.0 and has been committed to HEAD in July 2009 as comment#9 states. I have adjusted the metadata.
Thanks, Stefan!
Available in 3.0 GA: http://download.eclipse.org/modeling/emf/cdo/updates/3.0-releases/
