Re: [Xdoclet-user] Name unicity

[Jean-philippe V. <j-p...@st...>]

I agree with that.
The wrong design is using db constraint to manage rules which should be 
located in the business tier. That's to say not coding a rule because 
you know that a constraint has been set within the db.

But coding a business tier which is able to manage all rules without 
using constraint seems to be difficult and i don't know if following 
this theorical principle is possible. Especially in a multithreading 
environment.

I guess that if i have problem to check the unicity of a field, i will 
have some problems in coding more complex rules.

What is your mind about that? How do you check that something is unique?

Jean-Philippe
 

D....@ui... wrote:

>Hi,
>Whatever you do at the other tiers, I wouldn't call defining a PK a wrong
>design. That is ENFORCING a rule, it does not mean you have to let the DB handle
>the detection of a duplicated value, it just means that the DB won't allow you
>to introduce a duplicate value, in case you have bug or something similar, not
>unlikely to happen at the beginning in multithreaded environments. Another
>advantage is that if someday you introduce data in your DB through another tier,
>like a batch job with a bunch of SQL commands or a native application, the
>contraint is still enforced. IMHO, unless you put a lot of access restrictions
>on your DB, if you check all of that only at the upper tiers you cannot
>guarantee the data is consistent at the DB.
>Just my 2ec,
>D.
>
>  
>
>>Yes, but my name is no defined as a PK and i don't want to use unicity 
>>constraint (in fact i don't know if the default jboss database manages 
>>it, the @pk-constaint tag has no effect.
>>
>>Moreover, if your name is defined as a PK, you don't need any more to 
>>check the unicity and you have a wrong design with some rules managed by 
>>the db tier.
>>At least, i've been said that the ejb server can delay the call to 
>>ejbstore. In this case you get your  exception after the call (at the 
>>end of the transaction i guess) of the create function which can be 
>>difficult to manage.
>>    
>>
>
>
>--
>This message was sent using Sake Mail, a web-based email tool from
>Endymion Corporation.  http://www.endymion.com/products/sake
>
>  
>
>
> ------------------------------------------------------------------------
>
> Yes, but my name is no defined as a PK and i don't want to use unicity 
> constraint (in fact i don't know if the default jboss database manages 
> it, the @pk-constaint tag has no effect.
>
> Moreover, if your name is defined as a PK, you don't need any more to 
> check the unicity and you have a wrong design with some rules managed 
> by the db tier.
> At least, i've been said that the ejb server can delay the call to 
> ejbstore. In this case you get your  exception after the call (at the 
> end of the transaction i guess) of the create function which can be 
> difficult to manage.
>
> edu...@it... wrote:
>
>>If the name is defined as a PK I think you shouldn't have any problem...
>>
>>On Tue, 2003-07-29 at 03:46, Jean-philippe VIGNIEL wrote:
>>  
>>
>>>What appens if two persons create the same object at the same time. With 
>>>the default transaction mode, i think  (but i can be wrong) that the 
>>>object can be created twice.
>>>
>>>By example;
>>>
>>>User1: select * from object where name="bob"->nothing  so it's ok
>>>User2: select * from object where name="bob"->nothing so it's ok
>>>User1: create "bob"
>>>User2: create "bob"
>>>User1: close transaction
>>>User2: Close transaction
>>>
>>>And there are two bob objects within the database.
>>>
>>>
>>>Before EJB tomanage this case we did a select for update. Perhaps it's 
>>>possible to set the transaction mode to serialized for the create method???
>>>
>>>Thanks for your advice about with subject?
>>>
>>>
>>>    
>>>
>>
>>  
>>
>