Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Best way to support String ID
[CDO] Best way to support String ID [message #714168] Wed, 10 August 2011 00:26 Go to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
I am working with large models that have objects with String identifier attribute. The identifier is normally globally unique, in most cases GUID. (There are some use cases for working with models that are temporarily inconsistent, but lets forget about this for now.) One of the most common operations that have to be supported is object lookup by its identifier, this has to be very fast. (Let's also assume read-only scenario for now.)

What is the best way to implement this with CDO? Ideally the unique identifier would become / be used as CDOID, though that would only be possible with stores using String CDOIDs, right? Is maintaining a map from identifiers to CDOIDs the only way to make this generic? If yes, what would it take to maintain it on the server side and make it accessible to all clients?
Re: [CDO] Best way to support String ID [message #714244 is a reply to message #714168] Wed, 10 August 2011 06:40 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Alex,

Making an IStore understand and handle String IDs is not that easy if they not already can do it. But even that wouldn't
solve the problem completely because what you seem to wish is tat these String IDs are assigned at the client side and
then stored unchanged on the server. This is an entirely different behaviour across all established layers of CDO.

What a luck that this is nevertheless possible now in CDO 4.1:

336414: [DB] Make the used CDOIDObject subtype and storage pluggable
https://bugs.eclipse.org/bugs/show_bug.cgi?id=336414

352561: Support client assigned CDOIDs (UUIDs)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=352561

There's a new repository property:

<property name="idGenerationLocation" value="CLIENT"/> <!-- Possible values: STORE | CLIENT -->

And you *can* override the default ID generation at the client side with:

org.eclipse.emf.cdo.session.CDOSessionConfiguration.setIDGenerator(CDOIDGenerator)

prior to opening a session to your repository. Note that DBStore is currently the only IStore that supports client
assigned IDs.

This feature is brand new and I'd appreciate your feedback ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 10.08.2011 02:26, schrieb Alex:
> I am working with large models that have objects with String identifier attribute. The identifier is normally globally
> unique, in most cases GUID. (There are some use cases for working with models that are temporarily inconsistent, but
> lets forget about this for now.) One of the most common operations that have to be supported is object lookup by its
> identifier, this has to be very fast. (Let's also assume read-only scenario for now.)
>
> What is the best way to implement this with CDO? Ideally the unique identifier would become / be used as CDOID, though
> that would only be possible with stores using String CDOIDs, right? Is maintaining a map from identifiers to CDOIDs
> the only way to make this generic? If yes, what would it take to maintain it on the server side and make it accessible
> to all clients?


Re: [CDO] Best way to support String ID [message #714249 is a reply to message #714168] Wed, 10 August 2011 06:40 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Alex,

Making an IStore understand and handle String IDs is not that easy if they not already can do it. But even that wouldn't
solve the problem completely because what you seem to wish is tat these String IDs are assigned at the client side and
then stored unchanged on the server. This is an entirely different behaviour across all established layers of CDO.

What a luck that this is nevertheless possible now in CDO 4.1:

336414: [DB] Make the used CDOIDObject subtype and storage pluggable
https://bugs.eclipse.org/bugs/show_bug.cgi?id=336414

352561: Support client assigned CDOIDs (UUIDs)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=352561

There's a new repository property:

<property name="idGenerationLocation" value="CLIENT"/> <!-- Possible values: STORE | CLIENT -->

And you *can* override the default ID generation at the client side with:

org.eclipse.emf.cdo.session.CDOSessionConfiguration.setIDGenerator(CDOIDGenerator)

prior to opening a session to your repository. Note that DBStore is currently the only IStore that supports client
assigned IDs.

This feature is brand new and I'd appreciate your feedback ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 10.08.2011 02:26, schrieb Alex:
> I am working with large models that have objects with String identifier attribute. The identifier is normally globally
> unique, in most cases GUID. (There are some use cases for working with models that are temporarily inconsistent, but
> lets forget about this for now.) One of the most common operations that have to be supported is object lookup by its
> identifier, this has to be very fast. (Let's also assume read-only scenario for now.)
>
> What is the best way to implement this with CDO? Ideally the unique identifier would become / be used as CDOID, though
> that would only be possible with stores using String CDOIDs, right? Is maintaining a map from identifiers to CDOIDs
> the only way to make this generic? If yes, what would it take to maintain it on the server side and make it accessible
> to all clients?


Re: [CDO] Best way to support String ID [message #714293 is a reply to message #714244] Wed, 10 August 2011 08:42 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
To add to this :), the cdo hibernate store also supports string ids. This since CDO 3.0, but in a different way than
noted by Eike below: it is possible to annotate one of the efeatures with an @Id annotation. The value of this efeature
will be used by the Hibernate store as the id in the database and within CDO. The benefit of an explicitly modelled id
is that it is part of the object when (de-)serializing to xml/webservices.

gr. Martin

On 08/10/2011 08:40 AM, Eike Stepper wrote:
> Hi Alex,
>
> Making an IStore understand and handle String IDs is not that easy if they not already can do it. But even that wouldn't
> solve the problem completely because what you seem to wish is tat these String IDs are assigned at the client side and
> then stored unchanged on the server. This is an entirely different behaviour across all established layers of CDO.
>
> What a luck that this is nevertheless possible now in CDO 4.1:
>
> 336414: [DB] Make the used CDOIDObject subtype and storage pluggable
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=336414
>
> 352561: Support client assigned CDOIDs (UUIDs)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=352561
>
> There's a new repository property:
>
> <property name="idGenerationLocation" value="CLIENT"/> <!-- Possible values: STORE | CLIENT -->
>
> And you *can* override the default ID generation at the client side with:
>
> org.eclipse.emf.cdo.session.CDOSessionConfiguration.setIDGenerator(CDOIDGenerator)
>
> prior to opening a session to your repository. Note that DBStore is currently the only IStore that supports client
> assigned IDs.
>
> This feature is brand new and I'd appreciate your feedback ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 10.08.2011 02:26, schrieb Alex:
>> I am working with large models that have objects with String identifier attribute. The identifier is normally globally
>> unique, in most cases GUID. (There are some use cases for working with models that are temporarily inconsistent, but
>> lets forget about this for now.) One of the most common operations that have to be supported is object lookup by its
>> identifier, this has to be very fast. (Let's also assume read-only scenario for now.)
>>
>> What is the best way to implement this with CDO? Ideally the unique identifier would become / be used as CDOID, though
>> that would only be possible with stores using String CDOIDs, right? Is maintaining a map from identifiers to CDOIDs
>> the only way to make this generic? If yes, what would it take to maintain it on the server side and make it accessible
>> to all clients?


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Best way to support String ID [message #714990 is a reply to message #714293] Fri, 12 August 2011 01:58 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
> What a luck that this is nevertheless possible now in CDO 4.1:
and
> To add to this Smile, the cdo hibernate store also supports string ids.

Thank you. It is always a pleasant surprise when features one may need are anticipated, though in this modeling ecosystem it seems to be more of a pattern. I wonder how much of this is a natural property of the domain, where coherency rules and certain things just make sense, and how much is vision and dedication of individuals ...

Now, in my case the identifier attribute is indeed an intrinsic part of the model, in all its representations (so the Hibernate store approach of identifying it as such in Ecore would make sense.) Also, I don't really need clients assigning IDs (would this rule out using generic clients?), I'd rather have the server use the appropriate ID automatically instead. (And of course a mechanism that would ensure store portability would be preferred ... Wink To complete the picture, the current read-only scenarios do not need anything beyond a fast MEMStore (with enough memory) - though this is likely to change in the future, so maybe it is time I weaned myself off it ...

So it seems my options are:

1. Use Hibernate store approach, maybe with in-memory DB
2. Use DBStore with client (custom loader)-assigned string IDs, maybe with in-memory DB

3. Add pluggable and user-assigned ID capabilities to MEMStore, the rest as 2 ... How complex is that?
4. Use one of the string-ID capable stores with extra server-side logic to assign the ID from the attribute ... Any CDO assumptions/invariants violated? Too involved?

5. Use (and possibly maintain) separate ID-to-CDOID map, preferably on server; with any store. Is there a good place on the server side to plug this logic in? Could CDO mechanisms be used for remote lookup from client?

Did I miss anything? Any advice appreciated ...
Re: [CDO] Best way to support String ID [message #715052 is a reply to message #714990] Fri, 12 August 2011 08:20 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Ofcourse it is all vision :-), and the environment makes it easier also naturally...

The hibernate store will automatically use the efeature value as the cdoid, so no need to write server side logic for
that or additional maps.

For the other questions, Eike or others can better answer them.

gr. Martin

On 08/12/2011 03:58 AM, Alex wrote:
>> What a luck that this is nevertheless possible now in CDO 4.1:
> and
>> To add to this :), the cdo hibernate store also supports string ids.
>
> Thank you. It is always a pleasant surprise when features one may need are anticipated, though in this modeling
> ecosystem it seems to be more of a pattern. I wonder how much of this is a natural property of the domain, where
> coherency rules and certain things just make sense, and how much is vision and dedication of individuals ...
>
> Now, in my case the identifier attribute is indeed an intrinsic part of the model, in all its representations (so the
> Hibernate store approach of identifying it as such in Ecore would make sense.) Also, I don't really need clients
> assigning IDs (would this rule out using generic clients?), I'd rather have the server use the appropriate ID
> automatically instead. (And of course a mechanism that would ensure store portability would be preferred ... ;) To
> complete the picture, the current read-only scenarios do not need anything beyond a fast MEMStore (with enough memory) -
> though this is likely to change in the future, so maybe it is time I weaned myself off it ...
>
> So it seems my options are:
>
> 1. Use Hibernate store approach, maybe with in-memory DB
> 2. Use DBStore with client (custom loader)-assigned string IDs, maybe with in-memory DB
>
> 3. Add pluggable and user-assigned ID capabilities to MEMStore, the rest as 2 ... How complex is that?
> 4. Use one of the string-ID capable stores with extra server-side logic to assign the ID from the attribute ... Any CDO
> assumptions/invariants violated? Too involved?
>
> 5. Use (and possibly maintain) separate ID-to-CDOID map, preferably on server; with any store. Is there a good place on
> the server side to plug this logic in? Could CDO mechanisms be used for remote lookup from client?
>
> Did I miss anything? Any advice appreciated ...


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Best way to support String ID [message #715955 is a reply to message #714990] Tue, 16 August 2011 05:41 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 12.08.2011 03:58, schrieb Alex:
>> What a luck that this is nevertheless possible now in CDO 4.1:
> and
>> To add to this :), the cdo hibernate store also supports string ids.
>
> Thank you. It is always a pleasant surprise when features one may need are anticipated, though in this modeling
> ecosystem it seems to be more of a pattern. I wonder how much of this is a natural property of the domain, where
> coherency rules and certain things just make sense, and how much is vision and dedication of individuals ...
>
> Now, in my case the identifier attribute is indeed an intrinsic part of the model, in all its representations (so the
> Hibernate store approach of identifying it as such in Ecore would make sense.) Also, I don't really need clients
> assigning IDs (would this rule out using generic clients?), I'd rather have the server use the appropriate ID
> automatically instead.
The combination of a) server assigned IDs and b) modeled IDs is problematic because that implies that the server
*changes* the model during a commit operation. The CDO protocol does currently not support this use case and this
restriction is not related to any specific store. If you want me to add this capability, please contact me privately.

> (And of course a mechanism that would ensure store portability would be preferred ... ;) To complete the picture, the
> current read-only scenarios do not need anything beyond a fast MEMStore (with enough memory) - though this is likely
> to change in the future, so maybe it is time I weaned myself off it ...
>
> So it seems my options are:
>
> 1. Use Hibernate store approach, maybe with in-memory DB
The above restriction does also apply to HibernateStore.

> 2. Use DBStore with client (custom loader)-assigned string IDs, maybe with in-memory DB
You can configure a custom IDGenerator via CDOSessionConfiguration *before* you open a CDOSession.

>
> 3. Add pluggable and user-assigned ID capabilities to MEMStore, the rest as 2 ... How complex is that?
MEMStore does now support client assigned IDs.

> 4. Use one of the string-ID capable stores with extra server-side logic to assign the ID from the attribute ... Any
> CDO assumptions/invariants violated? Too involved?
That would be imaginable.

>
> 5. Use (and possibly maintain) separate ID-to-CDOID map, preferably on server; with any store. Is there a good place
> on the server side to plug this logic in?
That sounds very impacting for any IStore implementors.

> Could CDO mechanisms be used for remote lookup from client?
A custom IQueryHandler should be able to do the trick.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Did I miss anything? Any advice appreciated ...


Re: [CDO] Best way to support String ID [message #715985 is a reply to message #715955] Tue, 16 August 2011 07:03 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
To be complete, the hibernate store works with a client-side-assigned modeled id, so if there is an id-annotated
efeature it will use the value assigned to it as the cdoid on the server.

Btw, afaics it won't be difficult to write some application code to assign id's on the client when inserting (generating
a guid for the id value for example).

gr. Martin

On 08/16/2011 07:41 AM, Eike Stepper wrote:
> Am 12.08.2011 03:58, schrieb Alex:
>>> What a luck that this is nevertheless possible now in CDO 4.1:
>> and
>>> To add to this :), the cdo hibernate store also supports string ids.
>>
>> Thank you. It is always a pleasant surprise when features one may need are anticipated, though in this modeling
>> ecosystem it seems to be more of a pattern. I wonder how much of this is a natural property of the domain, where
>> coherency rules and certain things just make sense, and how much is vision and dedication of individuals ...
>>
>> Now, in my case the identifier attribute is indeed an intrinsic part of the model, in all its representations (so the
>> Hibernate store approach of identifying it as such in Ecore would make sense.) Also, I don't really need clients
>> assigning IDs (would this rule out using generic clients?), I'd rather have the server use the appropriate ID
>> automatically instead.
> The combination of a) server assigned IDs and b) modeled IDs is problematic because that implies that the server
> *changes* the model during a commit operation. The CDO protocol does currently not support this use case and this
> restriction is not related to any specific store. If you want me to add this capability, please contact me privately.
>
>> (And of course a mechanism that would ensure store portability would be preferred ... ;) To complete the picture, the
>> current read-only scenarios do not need anything beyond a fast MEMStore (with enough memory) - though this is likely
>> to change in the future, so maybe it is time I weaned myself off it ...
>>
>> So it seems my options are:
>>
>> 1. Use Hibernate store approach, maybe with in-memory DB
> The above restriction does also apply to HibernateStore.
>
>> 2. Use DBStore with client (custom loader)-assigned string IDs, maybe with in-memory DB
> You can configure a custom IDGenerator via CDOSessionConfiguration *before* you open a CDOSession.
>
>>
>> 3. Add pluggable and user-assigned ID capabilities to MEMStore, the rest as 2 ... How complex is that?
> MEMStore does now support client assigned IDs.
>
>> 4. Use one of the string-ID capable stores with extra server-side logic to assign the ID from the attribute ... Any
>> CDO assumptions/invariants violated? Too involved?
> That would be imaginable.
>
>>
>> 5. Use (and possibly maintain) separate ID-to-CDOID map, preferably on server; with any store. Is there a good place
>> on the server side to plug this logic in?
> That sounds very impacting for any IStore implementors.
>
>> Could CDO mechanisms be used for remote lookup from client?
> A custom IQueryHandler should be able to do the trick.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Did I miss anything? Any advice appreciated ...


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Best way to support String ID [message #716986 is a reply to message #714244] Fri, 19 August 2011 00:10 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
Eike Stepper wrote on Wed, 10 August 2011 02:40

352561: Support client assigned CDOIDs (UUIDs)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=352561

There's a new repository property:

<property name="idGenerationLocation" value="CLIENT"/> <!-- Possible values: STORE | CLIENT -->

And you *can* override the default ID generation at the client side with:

org.eclipse.emf.cdo.session.CDOSessionConfiguration.setIDGenerator(CDOIDGenerator)

prior to opening a session to your repository. Note that DBStore is currently the only IStore that supports client assigned IDs.


This does not seem to support client-side-assigned modeled IDs, does it? The CDOIDGenerator does not have access to the new object ...
Re: [CDO] Best way to support String ID [message #717010 is a reply to message #716986] Fri, 19 August 2011 04:31 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 19.08.2011 02:10, schrieb Alex:
> Eike Stepper wrote on Wed, 10 August 2011 02:40
>> 352561: Support client assigned CDOIDs (UUIDs)
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=352561
>>
>> There's a new repository property:
>>
>> <property name="idGenerationLocation" value="CLIENT"/> <!-- Possible values: STORE | CLIENT -->
>>
>> And you *can* override the default ID generation at the client side with:
>>
>> org.eclipse.emf.cdo.session.CDOSessionConfiguration.setIDGenerator(CDOIDGenerator)
>>
>> prior to opening a session to your repository. Note that DBStore is currently the only IStore that supports client
>> assigned IDs.
BTW. MEMStore does support them now, too.

>
>
> This does not seem to support client-side-assigned modeled IDs, does it?
No, and I doubt that would be a good idea. Models can change, IDs must not.

> The CDOIDGenerator does not have access to the new object ...
That doesn't seem useful for the generation of technical IDs.

I'd rather recommend to try it in the opposite direction: Let CDO's default CDOIDGenerator generate UUIDs (CDOIDs!) at
client side and model derived ID attributes that return the String value of this CDOID.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO] Best way to support String ID [message #717256 is a reply to message #717010] Fri, 19 August 2011 18:05 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
Eike Stepper wrote on Fri, 19 August 2011 00:31

>> Note that DBStore is currently the only IStore that supports client
>> assigned IDs.
BTW. MEMStore does support them now, too.


Great!

Eike Stepper wrote on Fri, 19 August 2011 00:31

> This does not seem to support client-side-assigned modeled IDs, does it?
No, and I doubt that would be a good idea. Models can change, IDs must not.

> The CDOIDGenerator does not have access to the new object ...
That doesn't seem useful for the generation of technical IDs.

I'd rather recommend to try it in the opposite direction: Let CDO's default CDOIDGenerator generate UUIDs (CDOIDs!) at
client side and model derived ID attributes that return the String value of this CDOID.


I can see how this is very useful in many scenarios. My use case is a little different however, I probably should have explained it better:

I have model instances coming into CDO with objects already having well-known, unique, pre-defined identifiers (happen to be one of the attributes). All that is needed is a way to lookup CDO object quickly using that well-known, pre-defined ID - e.g. in process of responding to an external query which specifies the ID. There are other model operations happening as well, but lookup of a single object via its [externally] well-known ID is very common and needs to be fast. In general, finding an object based on a value of a particular attribute is expensive. So, to provide an efficient lookup, it is either finding a way to make these well-known IDs become CDO IDs (and possibly getting rid of the explicit attribute) or building up and maintaining an ID-to-CDOID map (preferably maintained on server side available to all clients using e.g.IQueryHandler) ...
Re: [CDO] Best way to support String ID [message #717342 is a reply to message #717256] Sat, 20 August 2011 03:28 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Alex,

You've convinced me and I've implemented this enhancement for you:

355285: Make CDOIDGenerator aware of EObject
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355285

Please cc yourself to the bugzilla and report there if it works for you.

Note that, technically, a CDOIDGenerator implementation must be prepared for null to be passed in certain situations
where there is no EObject available.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 19.08.2011 20:05, schrieb Alex:
> Eike Stepper wrote on Fri, 19 August 2011 00:31
>> >> Note that DBStore is currently the only IStore that supports client >> assigned IDs.
>> BTW. MEMStore does support them now, too.
>
>
> Great!
>
> Eike Stepper wrote on Fri, 19 August 2011 00:31
>> > This does not seem to support client-side-assigned modeled IDs, does it? No, and I doubt that would be a good idea.
>> Models can change, IDs must not.
>>
>> > The CDOIDGenerator does not have access to the new object ...
>> That doesn't seem useful for the generation of technical IDs.
>>
>> I'd rather recommend to try it in the opposite direction: Let CDO's default CDOIDGenerator generate UUIDs (CDOIDs!)
>> at client side and model derived ID attributes that return the String value of this CDOID.
>
>
> I can see how this is very useful in many scenarios. My use case is a little different however, I probably should have
> explained it better:
>
> I have model instances coming into CDO with objects already having well-known, unique, pre-defined identifiers (happen
> to be one of the attributes). All that is needed is a way to lookup CDO object quickly using that well-known,
> pre-defined ID - e.g. in process of responding to an external query which specifies the ID. There are other model
> operations happening as well, but lookup of a single object via its [externally] well-known ID is very common and
> needs to be fast. In general, finding an object based on a value of a particular attribute is expensive. So, to
> provide an efficient lookup, it is either finding a way to make these well-known IDs become CDO IDs (and possibly
> getting rid of the explicit attribute) or building up and maintaining an ID-to-CDOID map (preferably maintained on
> server side available to all clients using e.g.IQueryHandler) ...


Re: [CDO] Best way to support String ID [message #717353 is a reply to message #717342] Sat, 20 August 2011 04:36 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 20.08.2011 05:28, schrieb Eike Stepper:
> Hi Alex,
>
> You've convinced me and I've implemented this enhancement for you:
>
> 355285: Make CDOIDGenerator aware of EObject
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=355285
Available in http://www.eclipse.org/cdo/downloads/#I20110818_0608

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> Please cc yourself to the bugzilla and report there if it works for you.
>
> Note that, technically, a CDOIDGenerator implementation must be prepared for null to be passed in certain situations
> where there is no EObject available.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 19.08.2011 20:05, schrieb Alex:
>> Eike Stepper wrote on Fri, 19 August 2011 00:31
>>> >> Note that DBStore is currently the only IStore that supports client >> assigned IDs.
>>> BTW. MEMStore does support them now, too.
>>
>>
>> Great!
>>
>> Eike Stepper wrote on Fri, 19 August 2011 00:31
>>> > This does not seem to support client-side-assigned modeled IDs, does it? No, and I doubt that would be a good idea.
>>> Models can change, IDs must not.
>>>
>>> > The CDOIDGenerator does not have access to the new object ...
>>> That doesn't seem useful for the generation of technical IDs.
>>>
>>> I'd rather recommend to try it in the opposite direction: Let CDO's default CDOIDGenerator generate UUIDs (CDOIDs!)
>>> at client side and model derived ID attributes that return the String value of this CDOID.
>>
>>
>> I can see how this is very useful in many scenarios. My use case is a little different however, I probably should
>> have explained it better:
>>
>> I have model instances coming into CDO with objects already having well-known, unique, pre-defined identifiers
>> (happen to be one of the attributes). All that is needed is a way to lookup CDO object quickly using that well-known,
>> pre-defined ID - e.g. in process of responding to an external query which specifies the ID. There are other model
>> operations happening as well, but lookup of a single object via its [externally] well-known ID is very common and
>> needs to be fast. In general, finding an object based on a value of a particular attribute is expensive. So, to
>> provide an efficient lookup, it is either finding a way to make these well-known IDs become CDO IDs (and possibly
>> getting rid of the explicit attribute) or building up and maintaining an ID-to-CDOID map (preferably maintained on
>> server side available to all clients using e.g.IQueryHandler) ...


Re: [CDO] Best way to support String ID [message #721121 is a reply to message #717342] Wed, 31 August 2011 22:54 Go to previous messageGo to next message
Alex Mising name is currently offline Alex Mising nameFriend
Messages: 51
Registered: August 2009
Member
Eike Stepper wrote on Fri, 19 August 2011 23:28
You've convinced me and I've implemented this enhancement for you:

355285: Make CDOIDGenerator aware of EObject
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355285

(Sorry for delay in responding, I was gone for a while ...)

This is great, thank you! Will try it out and report as soon as I can ...
Re: [CDO] Best way to support String ID [message #764121 is a reply to message #721121] Sun, 11 December 2011 12:18 Go to previous messageGo to next message
Eclipse UserFriend
Quote:
To be complete, the hibernate store works with a client-side-assigned modeled id, so if there is an id-annotated
efeature it will use the value assigned to it as the cdoid on the server.

Btw, afaics it won't be difficult to write some application code to assign id's on the client when inserting (generating
a guid for the id value for example).


I have tried this.
My ecore model contains:

Quote:
<eClassifiers xsi:type="ecore:EClass" name="Identifier" abstract="true" interface="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="id" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true">
<eAnnotations source="teneo.jpa">
<details key="value" value="@Id"/>
</eAnnotations>
</eStructuralFeatures>
</eClassifiers>


Most, but not all of the EClasses in the model have Identifier (mostly indirectly) in their superclasses.
teneo.naming.id_feature_as_primary_key is set to true
(The value of the id is generated in the constructor of the respective classes.)

I get "java.lang.String cannot be cast to java.lang.Long".

I admit that I don't understand hibernate's strategy for creating tables, and I have a guess that the problem might be related to that.

I attach my ecore model, the cdo server config, and the log with the stack trace for reference.
  • Attachment: cdo-server.xml
    (Size: 2.74KB, Downloaded 185 times)
  • Attachment: log.txt
    (Size: 536.73KB, Downloaded 576 times)
  • Attachment: archimate.ecore
    (Size: 20.67KB, Downloaded 157 times)
Re: [CDO] Best way to support String ID [message #764185 is a reply to message #764121] Sun, 11 December 2011 15:54 Go to previous messageGo to next message
Eclipse UserFriend
Okay, the problem came from the fact that a multiple instance feature which actually uses ArchimateModelElements which has string ID, has been declared to be EObject.
This is admittedly user error, and I understand that one should not mess with things one does not understand:)
However it would be a nice feature if some check would thrown an error in (table or code) generation time. I believe the necessary information is there.

  <eClassifiers xsi:type="ecore:EClass" name="Folder" eSuperTypes="#//ArchimateModelElement #//FolderContainer">
     <eStructuralFeatures xsi:type="ecore:EReference" name="elements" upperBound="-1"
-        eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject" containment="true"
-        resolveProxies="false"/>
+        eType="#//ArchimateModelElement" containment="true" resolveProxies="false"/>
     <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="#//FolderType"/>
   </eClassifiers>

Re: [CDO] Best way to support String ID [message #764191 is a reply to message #764185] Sun, 11 December 2011 16:14 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 11.12.2011 16:54, schrieb mag:
> Okay, the problem came from the fact that a multiple instance feature which actually uses ArchimateModelElements which
> has string ID, has been declared to be EObject.
> This is admittedly user error, and I understand that one should not mess with things one does not understand:)
> However it would be a nice feature if some check would thrown an error in (table or code) generation time.
Sorry, I don't understand what you mean. Can you explain in other words what you think is your "usage error"?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



> I believe the necessary information is there.
>
> <eClassifiers xsi:type="ecore:EClass" name="Folder" eSuperTypes="#//ArchimateModelElement #//FolderContainer">
> <eStructuralFeatures xsi:type="ecore:EReference" name="elements" upperBound="-1"
> - eType="ecore:EClass http://www.eclipse.org/emf/2002/Ecore#//EObject" containment="true"
> - resolveProxies="false"/>
> + eType="#//ArchimateModelElement" containment="true" resolveProxies="false"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="type" eType="#//FolderType"/>
> </eClassifiers>
>
>


Re: [CDO] Best way to support String ID [message #764256 is a reply to message #764191] Sun, 11 December 2011 19:25 Go to previous messageGo to next message
Eclipse UserFriend
The ecore model was looking like this:

There is an abstract class named ArchimateModelElement. All model elements are derived from this. This has been indirectly (through a supertype called Identifier) configured to use a string id through a hibernate annotation.
There is a EClass named Folder. It is meant to contain elements of the model: ArchimateModelElements, having string ids. But the type of the structural feature has been declared to be EObject, which is persisted with long ids.

As the string id has been declared through a hibernate annotation, it was not the responsibility of the code generator to detect this conflict. This is why I call it user error.
However I believe that the hibernate layer has the information to detect the type clash. And while it is true that if one wants to control the persistence by hand, then one should know how it works (and e.g. with sqlite it would have worked if we have sqlite binding for hibernate), it would have been a nice feature to warn about the type clash.

Now I have the problem, that I am using hibernate for persistence, and use this @Id annotation. And I would like to use branches, which are not supported using hibernate. Do we have a timeline for https://bugs.eclipse.org/bugs/show_bug.cgi?id=244141 ? Would I be better off using the CDO way described above in this thread?
Re: [CDO] Best way to support String ID [message #764270 is a reply to message #764121] Sun, 11 December 2011 20:08 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hmm, the id_feature_as_primary_key is not needed if you annotated with the @Id annotation. Did you start with a
new/empty database schema?

gr. Martin

On 12/11/2011 01:18 PM, mag wrote:
> Quote:
>> To be complete, the hibernate store works with a client-side-assigned modeled id, so if there is an id-annotated
>> efeature it will use the value assigned to it as the cdoid on the server.
>>
>> Btw, afaics it won't be difficult to write some application code to assign id's on the client when inserting (generating
>> a guid for the id value for example).
>
>
> I have tried this.
> My ecore model contains:
>
> Quote:
>> <eClassifiers xsi:type="ecore:EClass" name="Identifier" abstract="true" interface="true">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
>> iD="true">
>> <eAnnotations source="teneo.jpa">
>> <details key="value" value="@Id"/>
>> </eAnnotations>
>> </eStructuralFeatures>
>> </eClassifiers>
>
>
> Most, but not all of the EClasses in the model have Identifier (mostly indirectly) in their superclasses.
> teneo.naming.id_feature_as_primary_key is set to true
> (The value of the id is generated in the constructor of the respective classes.)
>
> I get "java.lang.String cannot be cast to java.lang.Long".
>
> I admit that I don't understand hibernate's strategy for creating tables, and I have a guess that the problem might be related to that.
>
> I attach my ecore model, the cdo server config, and the log with the stack trace for reference.


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Best way to support String ID [message #764274 is a reply to message #764256] Sun, 11 December 2011 20:17 Go to previous messageGo to next message
Martin Taal is currently offline Martin TaalFriend
Messages: 5468
Registered: July 2009
Senior Member
Hi,
Saw that I previously answered an old post. It gets quite difficult to detect these type of user errors in an
unambiguous/always correct/never-false-negative way...

I don't expect the hibernate store to support branching on the short term, unless there is someone who is prepared to
fund this effort (it is probably 10+ mandays of work...).

gr. Martin

On 12/11/2011 08:25 PM, mag wrote:
> The ecore model was looking like this:
>
> There is an abstract class named ArchimateModelElement. All model elements are derived from this. This has been
> indirectly (through a supertype called Identifier) configured to use a string id through a hibernate annotation.
> There is a EClass named Folder. It is meant to contain elements of the model: ArchimateModelElements, having string ids.
> But the type of the structural feature has been declared to be EObject, which is persisted with long ids.
>
> As the string id has been declared through a hibernate annotation, it was not the responsibility of the code generator
> to detect this conflict. This is why I call it user error.
> However I believe that the hibernate layer has the information to detect the type clash. And while it is true that if
> one wants to control the persistence by hand, then one should know how it works (and e.g. with sqlite it would have
> worked if we have sqlite binding for hibernate), it would have been a nice feature to warn about the type clash.
>
> Now I have the problem, that I am using hibernate for persistence, and use this @Id annotation. And I would like to use
> branches, which are not supported using hibernate. Do we have a timeline for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=244141 ? Would I be better off using the CDO way described above in this
> thread?
>


--

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
Re: [CDO] Best way to support String ID [message #764415 is a reply to message #764274] Mon, 12 December 2011 05:59 Go to previous message
Eclipse UserFriend
Yes, I started with a fresh database.
Thank you for the answer.
Previous Topic:[CDO]How to get different revision of a resource?
Next Topic:[CDO] Composite Model in CDO
Goto Forum:
  


Current Time: Thu Mar 28 16:51:46 GMT 2024

Powered by FUDForum. Page generated in 0.05675 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top