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]
