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: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
