db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: SECUENCE of PostgreSQL increment value if use QueryByIdentityandgetObjectByQuery
Date Thu, 13 Jan 2005 20:40:24 GMT
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


Mime
View raw message