You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Antonio Gallardo <ag...@agssa.net> on 2005/01/13 01:51:29 UTC
Re: SECUENCE of PostgreSQL increment value if use
QueryByIdentityand getObjectByQuery
Hi Armin!
Thanks for the replies! I was talking with Carlos and we think this is a
bug because we are quering and we will not expect changes on the database
while quering. Suppose someone is using a read-only one (on a CDROM)?
Checking in the RDBMS world, if we ask for:
SELECT count(*) FROM clients where cli_id = null;
The answer is 0 rows. No errors and not touched the Sequence at all.
Few minuts ago, Carlos tested other cases, for example, what could happen
if we are not using a sequence at all?
Answer: In this case, returns null! That is cool. :-D
In conclusion, we found that if we don't use sequences at all then:
if PK=null or PK!=null but the PK value does not match to a table row PK,
then it returns null. So that is what we could expect in the case of using
sequences.
WDYT?
Can you send me some hints, where I can find the classes and I will try to
fix this small problem? ;-)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use
QueryByIdentityandgetObjectByQuery
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:
It will be hard make OJB don't use null PK to detect new Objects.
On the other hand, really few people use PK= null. So I think is good to
apply the patch to both 1.0. and 1.1 until we find a better way to fix it.
Perhaps we can state on the dosc that OJB don't allow PK=null. Even
without the current patch this is true.
WDYT?
Best Regards,
Antonio Gallardo
On Jue, 13 de Enero de 2005, 13:27, Armin Waibel dijo:
> Hi Jakob,
>
> Jakob Braeuchi wrote:
>> hi armin, antonio,
>>
>> will this patch be applied to ojb 1.1 as well ? the tests run without
>> problems.
>>
>
> No problem I can apply this patch for 1.1 too.
> Do you think it's acceptable to forbid 'null' as value for PK fields?
> Antonio mentioned it in a previous post
> </snip>
> The suggested solution have a small problem too: In fact is possible to
> have a PK=null. And this should not be a problem. AFAIK, the condition
> that each PK must meet (in some DBs ie: PostgreSQL) is that it must be
> UNIQUE. It does not matter if PK= null because, in theory is possible to
> have 1 row with PK=null and this should be OK since it is the only one
> that use null as PK.
>
> While I understand almost nobody use a PK=null, I think we cannot restrict
> the use of this "DB feature".
>
> Now think what if a PK is composed of more than 1 fields. Here again, one
> of them can be null and this does not broke the DB, but the patch will
> fail.
> <snip>
>
> The problem is that OJB use such a 'null PK' check to detect "new
> objects" (better performance than always do a DB select).
>
> regards,
> Armin
>
>> jakob
>>
>> Armin Waibel schrieb:
>>
>>>
>>>
>>> Antonio Gallardo wrote:
>>>
>>>> Hi Armin!
>>>>
>>>> Thanks for the replies! I was talking with Carlos and we think this is
>>>> a
>>>> bug because we are quering and we will not expect changes on the
>>>> database
>>>> while quering. Suppose someone is using a read-only one (on a CDROM)?
>>>>
>>>> Checking in the RDBMS world, if we ask for:
>>>>
>>>> SELECT count(*) FROM clients where cli_id = null;
>>>>
>>>> The answer is 0 rows. No errors and not touched the Sequence at all.
>>>>
>>>> Few minuts ago, Carlos tested other cases, for example, what could
>>>> happen
>>>> if we are not using a sequence at all?
>>>> Answer: In this case, returns null! That is cool. :-D
>>>>
>>>> In conclusion, we found that if we don't use sequences at all then:
>>>>
>>>> if PK=null or PK!=null but the PK value does not match to a table row
>>>> PK,
>>>> then it returns null. So that is what we could expect in the case of
>>>> using
>>>> sequences.
>>>>
>>>> WDYT?
>>>>
>>>> Can you send me some hints, where I can find the classes and I will
>>>> try to
>>>> fix this small problem? ;-)
>>>>
>>>
>>> Have a look at PersistenceBrokerImpl line 1527.
>>>
>>> I attached a fix that should work (not tested).
>>>
>>> The main problem was Identity class. This class obtain new id's and
>>> set the PK values in the persistent object (if PK fields are null). In
>>> my opinion this should not happen (bad design), but to change this
>>> will be costly.
>>>
>>> regards,
>>> Armin
>>>
>>>
>>>> Best Regards,
>>>>
>>>> Antonio Gallardo.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> public Object getObjectByQuery(Query query) throws
>>> PersistenceBrokerException
>>> {
>>> Object result = null;
>>> if (query instanceof QueryByIdentity)
>>> {
>>> // example obj may be an entity or an Identity
>>> Object obj = query.getExampleObject();
>>> if (obj instanceof Identity)
>>> {
>>> Identity oid = (Identity) obj;
>>> result = getObjectByIdentity(oid);
>>> }
>>> else
>>> {
>>>
>>> if(!serviceBrokerHelper().hasNullPKField(getClassDescriptor(obj.getClass()),
>>> obj))
>>> {
>>> Identity oid =
>>> serviceIdentity().buildIdentity(obj);
>>> result = getObjectByIdentity(oid);
>>> }
>>> }
>>> }
>>> else
>>> {
>>> Class itemClass = query.getSearchClass();
>>> ClassDescriptor cld = getClassDescriptor(itemClass);
>>> /*
>>> use OJB intern Iterator, thus we are able to close used
>>> resources instantly
>>> */
>>> OJBIterator it = getIteratorFromQuery(query, cld);
>>> /*
>>> arminw:
>>> patch by Andre Clute, instead of taking the first found
>>> result
>>> try to get the first found none null result.
>>> He wrote:
>>> I have a situation where an item with a certain criteria
>>> is in my
>>> database twice -- once deleted, and then a non-deleted
>>> version of it.
>>> When I do a PB.getObjectByQuery(), the RsIterator get's
>>> both results
>>> from the database, but the first row is the deleted row,
>>> so my RowReader
>>> filters it out, and do not get the right result.
>>> */
>>> try
>>> {
>>> while (result==null && it.hasNext())
>>> {
>>> result = it.next();
>>> }
>>> } // make sure that we close the used resources
>>> finally
>>> {
>>> if(it != null) it.releaseDbResources();
>>> }
>>> }
>>> return result;
>>> }
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use QueryByIdentityand
getObjectByQuery
Posted by Armin Waibel <ar...@apache.org>.
Hi Jakob,
Jakob Braeuchi wrote:
> hi armin, antonio,
>
> will this patch be applied to ojb 1.1 as well ? the tests run without
> problems.
>
No problem I can apply this patch for 1.1 too.
Do you think it's acceptable to forbid 'null' as value for PK fields?
Antonio mentioned it in a previous post
</snip>
The suggested solution have a small problem too: In fact is possible to
have a PK=null. And this should not be a problem. AFAIK, the condition
that each PK must meet (in some DBs ie: PostgreSQL) is that it must be
UNIQUE. It does not matter if PK= null because, in theory is possible to
have 1 row with PK=null and this should be OK since it is the only one
that use null as PK.
While I understand almost nobody use a PK=null, I think we cannot restrict
the use of this "DB feature".
Now think what if a PK is composed of more than 1 fields. Here again, one
of them can be null and this does not broke the DB, but the patch will
fail.
<snip>
The problem is that OJB use such a 'null PK' check to detect "new
objects" (better performance than always do a DB select).
regards,
Armin
> jakob
>
> Armin Waibel schrieb:
>
>>
>>
>> Antonio Gallardo wrote:
>>
>>> Hi Armin!
>>>
>>> Thanks for the replies! I was talking with Carlos and we think this is a
>>> bug because we are quering and we will not expect changes on the
>>> database
>>> while quering. Suppose someone is using a read-only one (on a CDROM)?
>>>
>>> Checking in the RDBMS world, if we ask for:
>>>
>>> SELECT count(*) FROM clients where cli_id = null;
>>>
>>> The answer is 0 rows. No errors and not touched the Sequence at all.
>>>
>>> Few minuts ago, Carlos tested other cases, for example, what could
>>> happen
>>> if we are not using a sequence at all?
>>> Answer: In this case, returns null! That is cool. :-D
>>>
>>> In conclusion, we found that if we don't use sequences at all then:
>>>
>>> if PK=null or PK!=null but the PK value does not match to a table row
>>> PK,
>>> then it returns null. So that is what we could expect in the case of
>>> using
>>> sequences.
>>>
>>> WDYT?
>>>
>>> Can you send me some hints, where I can find the classes and I will
>>> try to
>>> fix this small problem? ;-)
>>>
>>
>> Have a look at PersistenceBrokerImpl line 1527.
>>
>> I attached a fix that should work (not tested).
>>
>> The main problem was Identity class. This class obtain new id's and
>> set the PK values in the persistent object (if PK fields are null). In
>> my opinion this should not happen (bad design), but to change this
>> will be costly.
>>
>> regards,
>> Armin
>>
>>
>>> Best Regards,
>>>
>>> Antonio Gallardo.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> public Object getObjectByQuery(Query query) throws
>> PersistenceBrokerException
>> {
>> Object result = null;
>> if (query instanceof QueryByIdentity)
>> {
>> // example obj may be an entity or an Identity
>> Object obj = query.getExampleObject();
>> if (obj instanceof Identity)
>> {
>> Identity oid = (Identity) obj;
>> result = getObjectByIdentity(oid);
>> }
>> else
>> {
>>
>> if(!serviceBrokerHelper().hasNullPKField(getClassDescriptor(obj.getClass()),
>> obj))
>> {
>> Identity oid = serviceIdentity().buildIdentity(obj);
>> result = getObjectByIdentity(oid);
>> }
>> }
>> }
>> else
>> {
>> Class itemClass = query.getSearchClass();
>> ClassDescriptor cld = getClassDescriptor(itemClass);
>> /*
>> use OJB intern Iterator, thus we are able to close used
>> resources instantly
>> */
>> OJBIterator it = getIteratorFromQuery(query, cld);
>> /*
>> arminw:
>> patch by Andre Clute, instead of taking the first found
>> result
>> try to get the first found none null result.
>> He wrote:
>> I have a situation where an item with a certain criteria
>> is in my
>> database twice -- once deleted, and then a non-deleted
>> version of it.
>> When I do a PB.getObjectByQuery(), the RsIterator get's
>> both results
>> from the database, but the first row is the deleted row,
>> so my RowReader
>> filters it out, and do not get the right result.
>> */
>> try
>> {
>> while (result==null && it.hasNext())
>> {
>> result = it.next();
>> }
>> } // make sure that we close the used resources
>> finally
>> {
>> if(it != null) it.releaseDbResources();
>> }
>> }
>> return result;
>> }
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use QueryByIdentityand
getObjectByQuery
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi armin, antonio,
will this patch be applied to ojb 1.1 as well ? the tests run without
problems.
jakob
Armin Waibel schrieb:
>
>
> Antonio Gallardo wrote:
>
>> Hi Armin!
>>
>> Thanks for the replies! I was talking with Carlos and we think this is a
>> bug because we are quering and we will not expect changes on the database
>> while quering. Suppose someone is using a read-only one (on a CDROM)?
>>
>> Checking in the RDBMS world, if we ask for:
>>
>> SELECT count(*) FROM clients where cli_id = null;
>>
>> The answer is 0 rows. No errors and not touched the Sequence at all.
>>
>> Few minuts ago, Carlos tested other cases, for example, what could happen
>> if we are not using a sequence at all?
>> Answer: In this case, returns null! That is cool. :-D
>>
>> In conclusion, we found that if we don't use sequences at all then:
>>
>> if PK=null or PK!=null but the PK value does not match to a table row PK,
>> then it returns null. So that is what we could expect in the case of
>> using
>> sequences.
>>
>> WDYT?
>>
>> Can you send me some hints, where I can find the classes and I will
>> try to
>> fix this small problem? ;-)
>>
>
> Have a look at PersistenceBrokerImpl line 1527.
>
> I attached a fix that should work (not tested).
>
> The main problem was Identity class. This class obtain new id's and set
> the PK values in the persistent object (if PK fields are null). In my
> opinion this should not happen (bad design), but to change this will be
> costly.
>
> regards,
> Armin
>
>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
>
> ------------------------------------------------------------------------
>
> public Object getObjectByQuery(Query query) throws PersistenceBrokerException
> {
> Object result = null;
> if (query instanceof QueryByIdentity)
> {
> // example obj may be an entity or an Identity
> Object obj = query.getExampleObject();
> if (obj instanceof Identity)
> {
> Identity oid = (Identity) obj;
> result = getObjectByIdentity(oid);
> }
> else
> {
> if(!serviceBrokerHelper().hasNullPKField(getClassDescriptor(obj.getClass()), obj))
> {
> Identity oid = serviceIdentity().buildIdentity(obj);
> result = getObjectByIdentity(oid);
> }
> }
> }
> else
> {
> Class itemClass = query.getSearchClass();
> ClassDescriptor cld = getClassDescriptor(itemClass);
> /*
> use OJB intern Iterator, thus we are able to close used
> resources instantly
> */
> OJBIterator it = getIteratorFromQuery(query, cld);
> /*
> arminw:
> patch by Andre Clute, instead of taking the first found result
> try to get the first found none null result.
> He wrote:
> I have a situation where an item with a certain criteria is in my
> database twice -- once deleted, and then a non-deleted version of it.
> When I do a PB.getObjectByQuery(), the RsIterator get's both results
> from the database, but the first row is the deleted row, so my RowReader
> filters it out, and do not get the right result.
> */
> try
> {
> while (result==null && it.hasNext())
> {
> result = it.next();
> }
> } // make sure that we close the used resources
> finally
> {
> if(it != null) it.releaseDbResources();
> }
> }
> return result;
> }
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use
QueryByIdentityandgetObjectByQuery
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 12 de Enero de 2005, 19:05, Armin Waibel dijo:
> Have a look at PersistenceBrokerImpl line 1527.
>
> I attached a fix that should work (not tested).
>
> The main problem was Identity class. This class obtain new id's and set
> the PK values in the persistent object (if PK fields are null). In my
> opinion this should not happen (bad design), but to change this will be
> costly.
I reviewed the code. You are totally right! The problem is in the design. :-(
The suggested solution have a small problem too: In fact is posible to
have a PK=null. And this should not be a problem. AFAIK, the condition
that each PK must meet (in some DBs ie: PostgreSQL) is that it must be
UNIQUE. It does not matter if PK= null because, in theory is posible to
have 1 row with PK=null and this should be OK since it is the only one
that use null as PK.
While I understand almost nobody use a PK=null, I think we cannot restrict
the use of this "DB feature".
Now think what if a PK is composed of more than 1 fields. Here again, one
of them can be null and this does not broke the DB, but the patch will
fail.
As you told, the problem is in the Identity design.
I see 2 posible solutions:
A-Specialize a new Identity Object for QueryByIdentity that will not try
to fill primary keys.
B-Add new methods in the current Identity to be used by QueryByIdentity
that will not try to retrieve new values for PK's.
WDYT?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use
QueryByIdentityandgetObjectByQuery
Posted by Antonio Gallardo <ag...@agssa.net>.
On Mie, 12 de Enero de 2005, 19:05, Armin Waibel dijo:
>
> Have a look at PersistenceBrokerImpl line 1527.
>
> I attached a fix that should work (not tested).
>
> The main problem was Identity class. This class obtain new id's and set
> the PK values in the persistent object (if PK fields are null). In my
> opinion this should not happen (bad design), but to change this will be
> costly.
Hi:
I am back. Thanks for the patch. I will try this now.
BTW, we also found if a PK is using sequences then the return value is
always null. The only problem is that is touching sequences.
Is posible to use a diferent identity class? Maybe this can fix the
problem. Anyway, I wil try the patch first and let you know the results.
;-)
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use
QueryByIdentityandgetObjectByQuery
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Armin:
I already tested the patch (in our application and using OJB junit). The
patch and seems to be working good. Attached is new eclipse generated
patch. It is the same as yours, but in a eclipse format to be easily
applied by anyone (right click on project team -> Apply patch....)
I tried to go into the Identity "web" and as you told it is very dificult
to get a truly solutions. Seems like Identity and related helpers methods
needs to be refactored.
Thanks again for help us in this problem. :-DD
Best regards,
Antonio Gallardo.
On Mie, 12 de Enero de 2005, 19:05, Armin Waibel dijo:
>
>
> Antonio Gallardo wrote:
>> Hi Armin!
>>
>> Thanks for the replies! I was talking with Carlos and we think this is a
>> bug because we are quering and we will not expect changes on the
>> database
>> while quering. Suppose someone is using a read-only one (on a CDROM)?
>>
>> Checking in the RDBMS world, if we ask for:
>>
>> SELECT count(*) FROM clients where cli_id = null;
>>
>> The answer is 0 rows. No errors and not touched the Sequence at all.
>>
>> Few minuts ago, Carlos tested other cases, for example, what could
>> happen
>> if we are not using a sequence at all?
>> Answer: In this case, returns null! That is cool. :-D
>>
>> In conclusion, we found that if we don't use sequences at all then:
>>
>> if PK=null or PK!=null but the PK value does not match to a table row
>> PK,
>> then it returns null. So that is what we could expect in the case of
>> using
>> sequences.
>>
>> WDYT?
>>
>> Can you send me some hints, where I can find the classes and I will try
>> to
>> fix this small problem? ;-)
>>
>
> Have a look at PersistenceBrokerImpl line 1527.
>
> I attached a fix that should work (not tested).
>
> The main problem was Identity class. This class obtain new id's and set
> the PK values in the persistent object (if PK fields are null). In my
> opinion this should not happen (bad design), but to change this will be
> costly.
>
> regards,
> Armin
>
>
>> Best Regards,
>>
>> Antonio Gallardo.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: SECUENCE of PostgreSQL increment value if use QueryByIdentityand
getObjectByQuery
Posted by Armin Waibel <ar...@apache.org>.
Antonio Gallardo wrote:
> Hi Armin!
>
> Thanks for the replies! I was talking with Carlos and we think this is a
> bug because we are quering and we will not expect changes on the database
> while quering. Suppose someone is using a read-only one (on a CDROM)?
>
> Checking in the RDBMS world, if we ask for:
>
> SELECT count(*) FROM clients where cli_id = null;
>
> The answer is 0 rows. No errors and not touched the Sequence at all.
>
> Few minuts ago, Carlos tested other cases, for example, what could happen
> if we are not using a sequence at all?
> Answer: In this case, returns null! That is cool. :-D
>
> In conclusion, we found that if we don't use sequences at all then:
>
> if PK=null or PK!=null but the PK value does not match to a table row PK,
> then it returns null. So that is what we could expect in the case of using
> sequences.
>
> WDYT?
>
> Can you send me some hints, where I can find the classes and I will try to
> fix this small problem? ;-)
>
Have a look at PersistenceBrokerImpl line 1527.
I attached a fix that should work (not tested).
The main problem was Identity class. This class obtain new id's and set
the PK values in the persistent object (if PK fields are null). In my
opinion this should not happen (bad design), but to change this will be
costly.
regards,
Armin
> Best Regards,
>
> Antonio Gallardo.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
>