Home » Modeling » EMF » [CDO] In-transaction unique ID generator?
| [CDO] In-transaction unique ID generator? [message #1137505] |
Mon, 14 October 2013 14:43  |
 Alexandre Borgoltz
Messages: 31
Registered: July 2009
Location: France |
Member |
|
|
Hi,
In my application, I create orders. Order is an eClass with an EString attribute "id". The id of an order has obviously to be unique, and "human-managable" - currently we are using a long.
Until today, we were using the following small hack to retreive the cdoID of the order to fetch it into the "ID" attribute (using CDO 4.1) :
public class OrderImpl extends CDOObjectImpl implements Order {
//...
@Override
public void cdoInternalSetID(CDOID id) {
super.cdoInternalSetID(id);
if(null==getId()) {
long newId = Long.parseLong(id.toURIFragment());
eSet(MyPackage.ORDER__ID, newId);
}
}
//...
}
So the ID is unset until the order is committed to CDO. Then at commit, the ID is set (once for all) and will remain constant.
It has the nice quality that i can export/reimport an order without changing its ID (the re-imported order will have different id and cdoId but that is not a problem) while automatically assigning a unique ID to new orders.
I know it is not very clean - but it's been working nicely with almost no cost...
At that point, you may ask "SO WHAT!?". Here it is 
We are now willing to move on from CDO 4.1 to CDO 4.2. And the hack isn't possible anymore because cdoInternalSetID() has become final (and i guess it should always have been so!). Look like the perfect moment to clean up my code a little bit...
My question : how do you advise I should retreive the "next id" on order creation?
That id has to be unique amongst clients and so can hardly be generated on client side. It also should be somehow human-readable/manageable (UUIDs might not be an option).
- Should I be creating an additional fake eClass "Sequence" with one single instance in the repo, and implement a lock-read-increment-unlock mecanism? (not that sexy...)
- Should I setup a dedicated server (web?)app with one single method "getNextID()"?
- Should I write a custom net4j protocol that would be handled by a specific handler in CDO, transforming CDO into some kind of an appserver?
- ... ?
I thank you in advance for your feedback!
--
Alexandre
[Updated on: Mon, 14 October 2013 14:44] Report message to a moderator |
|
|
| Re: [CDO] In-transaction unique ID generator? [message #1137668 is a reply to message #1137505] |
Mon, 14 October 2013 17:01  |
Alexandre Borgoltz
Messages: 31
Registered: July 2009
Location: France |
Member |
|
|
After a little bit of thinking, I think I could rephrase my question like this:
Overring CDOObjectImpl.cdoInternalSetID() was a mean to be notified that a cdoID has been assigned to this object. As of 4.2, this isn't possible anymore. Is there an alternate way to do it? If not, wouldn't it be interesting to add public methods that could be overriden (or an equivalent listener mechanism)?
This question also applies to other cdoInternal*() methods, such as cdoInternalPreLoad(), PostLoad, Attach, Rollback, Commit .....
Following that approach, I have worked around the problem by adding a CDOObjectHandler to my CDOView and CDOTransactions :
CDOObjectHandler handler = new CDOObjectHandler() {
@Override
public void objectStateChanged(CDOView view, CDOObject object, CDOState oldState, CDOState newState) {
if(newState.equals(CDOState.NEW)) {
// object.cdoID is populated, use it e.g. to populate your order's id...
// ...
}
}
}
transaction.addObjectHandler(handler);
I can wait with that - but anyway, I'd be curious to know how others do solve the "unique stuff generation" in a more general manner...
HTH,
--
Alexandre
|
|
|
| Re: [CDO] In-transaction unique ID generator? [message #1137682 is a reply to message #1137668] |
Mon, 14 October 2013 17:09 |
|
Am 14.10.2013 19:01, schrieb Alexandre Borgoltz:
> After a little bit of thinking, I think I could rephrase my question like this:
>
> Overring CDOObjectImpl.cdoInternalSetID() was a mean to be notified that a cdoID has been assigned to this object. As
> of 4.2, this isn't possible anymore. Is there an alternate way to do it? If not, wouldn't it be interesting to add
> public methods that could be overriden (or an equivalent listener mechanism)?
>
> This question also applies to other cdoInternal*() methods, such as cdoInternalPreLoad(), PostLoad, Attach, Rollback,
> Commit .....
>
>
> Following that approach, I have worked around the problem by adding a CDOObjectHandler to my CDOView and
> CDOTransactions :
>
>
> CDOObjectHandler handler = new CDOObjectHandler() {
>
> @Override
> public void objectStateChanged(CDOView view, CDOObject object, CDOState oldState, CDOState newState) {
> if(newState.equals(CDOState.NEW)) {
> // object.cdoID is populated, use it e.g. to populate your order's id...
> // ...
> }
> }
> }
> transaction.addObjectHandler(handler);
Good that I read your second post, too, because that's exactly what I was going to suggest ;-)
>
> I can wait with that - but anyway, I'd be curious to know how others do solve the "unique stuff generation" in a more
> general manner...
Some other folks are using client-side assigned IDs (see cdo-server.xml) and with custom CDOIDGenrators in the
CDOSession, but that creates a database with all ID columns being VARCHAR!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Wed Sep 25 23:58:31 GMT 2024
Powered by FUDForum. Page generated in 0.06142 seconds |
] 
Search
Help
Register
Login
Home
