Re: sequential numbering across more instances
Re: sequential numbering across more instances
- Subject: Re: sequential numbering across more instances
- From: Ondřej Čada <email@hidden>
- Date: Fri, 15 Aug 2008 17:59:31 +0200
Florijan,
On Aug 15, 2008, at 5:33 PM, Florijan Stamenkovic wrote:
I regret to say I have a very strong feeling against using PK's for
anything but PK and relationships, ever.
May I ask why?
With any such value there is some probability the client will (next
week or next year) want (a) to edit it, (b) in some special case, to
have non-unique values. If PK is used, (a) is very inconvenient, and
(b) next to impossible.
I've found them quite useful when it comes to having immutable row /
EO identifiers
That might be all right, far as these identifiers are not visible to
the user. But I am digressing, sorry...
have not bumped into problems with this yet. Except that for some
reason in FrontBase they start with something like 100001, which I
have yet to deal with.
Never tried myself (for obvious reasons never needed), but I _think_
if you just manually fix the "UNIQUE" values in the SQL generated from
EOModeller, you are done.
Anyway, even if I wanted to use them, it would not do, for there
are items which have no numbers... Ha, thanks! Seems you just have
led me to one reason I haven't realised originally why UNIQUE would
not work quite well :) (Unless put into a table of its own,
dedicated for this task, which I at the moment have alas completely
no idea whether it's worth that or not... I think rather not?)
This can be worked around, with a boolean control property, let's
call it hasOrderNumber:
public Number orderNumber(){
if(hasOrderNumber)
return sequenceNumber();
else
return null;
}
That -- same as an extra UNIQUE column -- would not satisfy the demand
that "all numbered orders make a sequence 1,2,3,4,....". The client
would prefer that the sequence is without gaps (not something like
"1,5,6,27,....").
From what I know of this problem, it is virtually impossible to
ensure uniqueness of data in a WO setup in your Java code.
Locking (both pessimistic or optimistic) should help, I think?!? Seems
I am overlooking something else...
For a recent discussion on this, in which I was trying something
similar, check out the "DB uniqueness constraints and dealing with
them" (July this year).
... will study the thread, thanks!
So, after some valuable advice, I decided not to try to address this
in Java. I guess that in your situation a combination between a
database generated sequence and a uniqueness restraint would do what
you need. Some database I believe can generate this for you. In
others you might need to use a stored procedure to do it.
Could be. Anyway, the application uses FrontBase, and the probability
the client would ever switch to another SQL server is extremely
remote, so I can afford to stick with FrontBase tools.
Thanks!
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden