You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Guido Beutler <gu...@hrs.de> on 2004/03/29 17:19:45 UTC
Insert instead of update generated in RC6
Hello,
I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with DB2 V8.
Since update to RC6 OJB generates a insert for every stored object when
using PB API.
OJB seems not to check if the object exists at database. If the object
already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try to
insert the same object
several times, every time the same exception is thrown. If I select the
object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at the
test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Armin Waibel wrote:
> Guido Beutler wrote:
>
>> Hi,
>>
>> changing
>>
>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>> {
>> .....
>> if(((aValue instanceof Number) && (((Number)
>> aValue).longValue() == 0)))
>> {
>> >>> result =
>> fld.getPersistentField().getType().isPrimitive() && fld.isPrimaryKey();
>> }
>> ....
>> return result;
>> }
>>
>> into
>>
>> result = fld.getPersistentField().getType().isPrimitive() && !
>> fld.isPrimaryKey();
>> seems to fix my problem,
>> updates are generated now and insert's work too.
>> One of our OJB Guru's like Armin should take a look on it. ;-)
>> I just made some small tests and can not be sure that this don't
>> produce some side effects.
>> If my fix is correct, updates never worked for objects with 0 values
>> at primary key fields.
>>
>
> Maybe I'm on the wrong tack, but I don't figure out the change. This
> method should return 'true'
> - when the field as number of '0'
> - and the field is primitive (short in your case)
> - and the field-descriptor is declared as PK
Yes and I think the second is not correct. 0 at primary key's,
especially if the column is only one of a set of pk columns,
is a legal value, maybe that I'm wrong of course. I like using primitive
fields at my data classes, because they are fast,
small and I can avoid converting everything from int to Integer and back
again. Of course this is only one (my) opinion.
>
> In your patch you return true, when the field was not declared as PK.
> But in that case all values are valid ('0' too). Your patch do the
> opposite from what I expected. Maybe I'm completely confused ;-)
You're right, this is nonsens. :-)
Throwing away the rule would work for me too.
>
> Again, if you have a class with primitive short field, declared as PK
> with value '0', OJB assume that the field is nullified and because PK
> couldn't be 'null' OJB assume the given object was new.
At repository_user.xml I can define attributes like:
<field-descriptor id="1"
name="col"
column="col"
jdbc-type="INTEGER"
conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion"
/>
I thought, this is legal for PK fields too. Am I wrong with that?
The behavior to handle int 0 values as null values is new in RC6. In RC5
OJB stored a 0 if no additional conversion was defined.
I thought that the additional conversion was build to handle exact this
behavior.
In relational databases 0 is a legal pk value too and may exist in many
databases. Why restrict this when using OJB ?
Edson is right with his suggestion, that testing for auto-increment
would solve my problem too,
but I still don't understand why it is necessary to test for 0 in
primitive types. If I define a primitive type and don't
add a special conversion I documented at the repository that I know that
0 is treated as 0 (like in RC5 ).
Maybe that I documented that this is a bad mapping too :-)
I thought using primitive types means that you can never write a null
value. In my current application I can live with that
and prefer to use the performance improvement of primitives. In other
applications other mappings are better.
best regards,
Guido
> Hope I don't make a fool of oneself ;-)
>
> regards,
> Armin
>
>> best regards,
>>
>> Guido
>>
>>
>> Guido Beutler wrote:
>>
>>> Guido Beutler wrote:
>>>
>>>> Armin Waibel wrote:
>>>>
>>>>> do you use anonymous keys? If so where?
>>>>>
>>>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>>>>> >> results?
>>>>>
>>>>> No, can you describe this problem again? Should I update to JBoss
>>>>> 3.2.3 and run the tests again?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> we had the problem, that not all objects were returned by OJB. This
>>>> seemed to be a side effect of the eager-release
>>>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe
>>>> that the bahavior of our current problem is different
>>>> in 3.2.3.
>>>> I'll put some debug gcode into PersistenceBroker and see what's
>>>> going on during insert/update.
>>>>
>>>> best regards,
>>>>
>>>> Guido
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> I added some debug code to
>>>
>>> PersistenceBrokerImpl :
>>>
>>> public void store(Object obj) throws PersistenceBrokerException
>>> {
>>>
>>> ...
>>>
>>> boolean doInsert =
>>> serviceBrokerHelper().hasNullPKField(cld, obj);
>>>
>>> returns true. The reason seems to be BrokerHelper.representsNull :
>>>
>>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>>> {
>>> .....
>>> if(((aValue instanceof Number) && (((Number)
>>> aValue).longValue() == 0)))
>>> {
>>> result = fld.getPersistentField().getType().isPrimitive()
>>> && fld.isPrimaryKey();
>>> }
>>> ....
>>> return result;
>>> }
>>>
>>> returns true for my SMALLINT objects if the value is 0. But 0 is a
>>> leagal value for SMALLINT PK attributes.
>>> After that PersistenceBrokerImpl.store checks the cache:
>>>
>>> /*
>>> if PK values are set, lookup cache or db to see whether
>>> object
>>> needs insert or update
>>> */
>>> if (!doInsert)
>>> {
>>> doInsert = objectCache.lookup(oid) == null
>>> && !serviceBrokerHelper().doesExist(cld, oid, obj);
>>> }
>>>
>>> because of doInsert is still true (I checked it) The cache is never
>>> checked for the object. doInsert is still true and
>>> a few lines later
>>>
>>> // now store it:
>>> store(obj, oid, cld, doInsert);
>>>
>>> generates the insert statement. Maybe I'm wrong but for me it looks
>>> like a 0 (not null) at any PK field causes a insert statement.
>>> In my case it is immediately the first object. Is it a good idea to
>>> check the cache independent if doInsert is true or is the
>>> implementation
>>> of representsNull the cause and should be changed ?
>>>
>>> best regards,
>>>
>>> Guido
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br>.
I agree with you. Conversion is one way to get things working, as OJB
executing a select to test with already exists a record with PK 0 is
another way.
The auto-increment field should be tested when in PK that is inherently
not-null. In this case, there is no other way (exception if we create a
nullable attribute for field-descriptors).
About the 0 in multi-pk fields, I agree. My comments look about single
PK fields.
I'm just trying to get a new point of view in the discussion, because I
use largelly int in PK, and changes in this behaviour can affect our
projects (fortunatelly, since we never use 0 as valid value for PKs, we
had no problems like reported by you)...
My propose is not change current behaviour, but add non-invasive options
to manipulate behaviour of OJB.
May be docs should point the developer to use the conversion when he
want's the mapping from 0 to null, and make OJB doens't making this
conversion automatically, BUT in case of auto-increment fields I don't
see much scape. A declared int field will be 0 even if the value is not
set... So how can I inform OJB that this is a new field? Should we take
in count that this is a multi-pk, 0 is not converted? Maybe the simple
to understand, an less intrusive make OJB:
a) don't convert automatically 0 to null;
b) when auto-increment is set, consider 0 as new auto-calculated value.
c) convert 0 to null and vice-versa when using int2IntegerConversion.
Best regards,
Edson Richter
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Hi,
Edson Carlos Ericksson Richter wrote:
> Let me make some comments:
>
> Using primitive, then there is no other way to specify a nullability.
> I think we can take to the developer a choice to use nullable and
> primitive int but keep it always warned that 0 will save NULL in the
> database, and a NULL in database will, in turn, be converted to a 0 in
> primitive field. I think a WARN in docs is sufficient.
At repository_user.xml I can define attributes like:
<field-descriptor id="1"
name="col"
column="col"
jdbc-type="INTEGER"
conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion"
/>
I think this is the correct way to tell OJB if 0 should represent null
or not. The behavior to handle int 0 values as null values
is new in RC6. In RC5 OJB stored a 0 if no aditional conversion was defined.
>
> Maybe a future "nullable" attribute in field-descritor could help,
> with values "zeroIsNull", "negativeIsNull", "false", "true" (where
> false means default action: 0 == 0, -1 == -1, and true means actual
> behaviour 0==null. The other options talk by itself).
>
I think the conversion always solves the problem but of course this
would work too.
> But in PK, that doesn't allow NULL, if the primitive field is 0 we can
> have two situations: if the mapping tell us that there is an
> auto-increment field, then user doesn't want a real 0, but a newly
> inserted field. Auto-increments, as far as I have seen don't use 0 as
> starting point.
>
I think using autoincrement isn't as clear as a nullable attribute or
conversion.
> <comment type="maybe_offtopic">As interesting history, some weeks ago
> a beginner developer asked me about a product type codes: 0 - Service,
> 1 - Resale product, 2 - Own factoried product. I said to him: never,
> ever, use 0 as PK to avoid problems for understanding. In meantime,
> another begginer at his side said "0, in my point of view, is expected
> to means nothing, so I'll never use it as value for a PK". I'm tending
> to agree with this vision.</comment>
If the table has only one pk field I would agree with that but there may
be tables with several pk fields. I don't think that defining
don't use 0 in pk fields is a general rule for those tables.
>
> So, OJB could test if the field is auto-increment, and, if true, then
> assume that it's a new record being inserted. If false, assume that
> it's a 0 since there is no NULLs in PKs, and should be a update if
> already exists. This change, as far as I can see, will not change the
> current behaviour of OJB, right?
Would work, but I still don't understand why not using conversion.
best regards,
Guido
>
> Just my 2 cents,
>
> Edson Richter
>
>
> Armin Waibel wrote:
>
>> Guido Beutler wrote:
>>
>>> Hi,
>>>
>>> changing
>>>
>>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>>> {
>>> .....
>>> if(((aValue instanceof Number) && (((Number)
>>> aValue).longValue() == 0)))
>>> {
>>> >>> result =
>>> fld.getPersistentField().getType().isPrimitive() && fld.isPrimaryKey();
>>> }
>>> ....
>>> return result;
>>> }
>>>
>>> into
>>>
>>> result = fld.getPersistentField().getType().isPrimitive() && !
>>> fld.isPrimaryKey();
>>> seems to fix my
>>> problem, updates are generated now and insert's work too.
>>> One of our OJB Guru's like Armin should take a look on it. ;-)
>>> I just made some small tests and can not be sure that this don't
>>> produce some side effects.
>>> If my fix is correct, updates never worked for objects with 0 values
>>> at primary key fields.
>>>
>>
>> Maybe I'm on the wrong tack, but I don't figure out the change. This
>> method should return 'true'
>> - when the field as number of '0'
>> - and the field is primitive (short in your case)
>> - and the field-descriptor is declared as PK
>>
>> In your patch you return true, when the field was not declared as PK.
>> But in that case all values are valid ('0' too). Your patch do the
>> opposite from what I expected. Maybe I'm completely confused ;-)
>>
>> Again, if you have a class with primitive short field, declared as PK
>> with value '0', OJB assume that the field is nullified and because PK
>> couldn't be 'null' OJB assume the given object was new.
>> Hope I don't make a fool of oneself ;-)
>>
>> regards,
>> Armin
>>
>>> best regards,
>>>
>>> Guido
>>>
>>>
>>> Guido Beutler wrote:
>>>
>>>> Guido Beutler wrote:
>>>>
>>>>> Armin Waibel wrote:
>>>>>
>>>>>> do you use anonymous keys? If so where?
>>>>>>
>>>>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with
>>>>>> missing
>>>>>> >> results?
>>>>>>
>>>>>> No, can you describe this problem again? Should I update to JBoss
>>>>>> 3.2.3 and run the tests again?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> we had the problem, that not all objects were returned by OJB.
>>>>> This seemed to be a side effect of the eager-release
>>>>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe
>>>>> that the bahavior of our current problem is different
>>>>> in 3.2.3.
>>>>> I'll put some debug gcode into PersistenceBroker and see what's
>>>>> going on during insert/update.
>>>>>
>>>>> best regards,
>>>>>
>>>>> Guido
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I added some debug code to
>>>>
>>>> PersistenceBrokerImpl :
>>>>
>>>> public void store(Object obj) throws PersistenceBrokerException
>>>> {
>>>>
>>>> ...
>>>>
>>>> boolean doInsert =
>>>> serviceBrokerHelper().hasNullPKField(cld, obj);
>>>>
>>>> returns true. The reason seems to be BrokerHelper.representsNull :
>>>>
>>>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>>>> {
>>>> .....
>>>> if(((aValue instanceof Number) && (((Number)
>>>> aValue).longValue() == 0)))
>>>> {
>>>> result =
>>>> fld.getPersistentField().getType().isPrimitive() &&
>>>> fld.isPrimaryKey();
>>>> }
>>>> ....
>>>> return result;
>>>> }
>>>>
>>>> returns true for my SMALLINT objects if the value is 0. But 0 is a
>>>> leagal value for SMALLINT PK attributes.
>>>> After that PersistenceBrokerImpl.store checks the cache:
>>>>
>>>> /*
>>>> if PK values are set, lookup cache or db to see whether
>>>> object
>>>> needs insert or update
>>>> */
>>>> if (!doInsert)
>>>> {
>>>> doInsert = objectCache.lookup(oid) == null
>>>> && !serviceBrokerHelper().doesExist(cld, oid, obj);
>>>> }
>>>>
>>>> because of doInsert is still true (I checked it) The cache is never
>>>> checked for the object. doInsert is still true and
>>>> a few lines later
>>>>
>>>> // now store it:
>>>> store(obj, oid, cld, doInsert);
>>>>
>>>> generates the insert statement. Maybe I'm wrong but for me it looks
>>>> like a 0 (not null) at any PK field causes a insert statement.
>>>> In my case it is immediately the first object. Is it a good idea to
>>>> check the cache independent if doInsert is true or is the
>>>> implementation
>>>> of representsNull the cause and should be changed ?
>>>>
>>>> best regards,
>>>>
>>>> Guido
>>>>
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Edson Carlos Ericksson Richter <ed...@mgrinformatica.com.br>.
Let me make some comments:
Using primitive, then there is no other way to specify a nullability. I
think we can take to the developer a choice to use nullable and
primitive int but keep it always warned that 0 will save NULL in the
database, and a NULL in database will, in turn, be converted to a 0 in
primitive field. I think a WARN in docs is sufficient.
Maybe a future "nullable" attribute in field-descritor could help, with
values "zeroIsNull", "negativeIsNull", "false", "true" (where false
means default action: 0 == 0, -1 == -1, and true means actual behaviour
0==null. The other options talk by itself).
But in PK, that doesn't allow NULL, if the primitive field is 0 we can
have two situations: if the mapping tell us that there is an
auto-increment field, then user doesn't want a real 0, but a newly
inserted field. Auto-increments, as far as I have seen don't use 0 as
starting point.
<comment type="maybe_offtopic">As interesting history, some weeks ago a
beginner developer asked me about a product type codes: 0 - Service, 1 -
Resale product, 2 - Own factoried product. I said to him: never, ever,
use 0 as PK to avoid problems for understanding. In meantime, another
begginer at his side said "0, in my point of view, is expected to means
nothing, so I'll never use it as value for a PK". I'm tending to agree
with this vision.</comment>
So, OJB could test if the field is auto-increment, and, if true, then
assume that it's a new record being inserted. If false, assume that it's
a 0 since there is no NULLs in PKs, and should be a update if already
exists. This change, as far as I can see, will not change the current
behaviour of OJB, right?
Just my 2 cents,
Edson Richter
Armin Waibel wrote:
> Guido Beutler wrote:
>
>> Hi,
>>
>> changing
>>
>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>> {
>> .....
>> if(((aValue instanceof Number) && (((Number)
>> aValue).longValue() == 0)))
>> {
>> >>> result =
>> fld.getPersistentField().getType().isPrimitive() && fld.isPrimaryKey();
>> }
>> ....
>> return result;
>> }
>>
>> into
>>
>> result = fld.getPersistentField().getType().isPrimitive() && !
>> fld.isPrimaryKey();
>> seems to fix my problem,
>> updates are generated now and insert's work too.
>> One of our OJB Guru's like Armin should take a look on it. ;-)
>> I just made some small tests and can not be sure that this don't
>> produce some side effects.
>> If my fix is correct, updates never worked for objects with 0 values
>> at primary key fields.
>>
>
> Maybe I'm on the wrong tack, but I don't figure out the change. This
> method should return 'true'
> - when the field as number of '0'
> - and the field is primitive (short in your case)
> - and the field-descriptor is declared as PK
>
> In your patch you return true, when the field was not declared as PK.
> But in that case all values are valid ('0' too). Your patch do the
> opposite from what I expected. Maybe I'm completely confused ;-)
>
> Again, if you have a class with primitive short field, declared as PK
> with value '0', OJB assume that the field is nullified and because PK
> couldn't be 'null' OJB assume the given object was new.
> Hope I don't make a fool of oneself ;-)
>
> regards,
> Armin
>
>> best regards,
>>
>> Guido
>>
>>
>> Guido Beutler wrote:
>>
>>> Guido Beutler wrote:
>>>
>>>> Armin Waibel wrote:
>>>>
>>>>> do you use anonymous keys? If so where?
>>>>>
>>>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>>>>> >> results?
>>>>>
>>>>> No, can you describe this problem again? Should I update to JBoss
>>>>> 3.2.3 and run the tests again?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> we had the problem, that not all objects were returned by OJB. This
>>>> seemed to be a side effect of the eager-release
>>>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe
>>>> that the bahavior of our current problem is different
>>>> in 3.2.3.
>>>> I'll put some debug gcode into PersistenceBroker and see what's
>>>> going on during insert/update.
>>>>
>>>> best regards,
>>>>
>>>> Guido
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> I added some debug code to
>>>
>>> PersistenceBrokerImpl :
>>>
>>> public void store(Object obj) throws PersistenceBrokerException
>>> {
>>>
>>> ...
>>>
>>> boolean doInsert =
>>> serviceBrokerHelper().hasNullPKField(cld, obj);
>>>
>>> returns true. The reason seems to be BrokerHelper.representsNull :
>>>
>>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>>> {
>>> .....
>>> if(((aValue instanceof Number) && (((Number)
>>> aValue).longValue() == 0)))
>>> {
>>> result = fld.getPersistentField().getType().isPrimitive()
>>> && fld.isPrimaryKey();
>>> }
>>> ....
>>> return result;
>>> }
>>>
>>> returns true for my SMALLINT objects if the value is 0. But 0 is a
>>> leagal value for SMALLINT PK attributes.
>>> After that PersistenceBrokerImpl.store checks the cache:
>>>
>>> /*
>>> if PK values are set, lookup cache or db to see whether
>>> object
>>> needs insert or update
>>> */
>>> if (!doInsert)
>>> {
>>> doInsert = objectCache.lookup(oid) == null
>>> && !serviceBrokerHelper().doesExist(cld, oid, obj);
>>> }
>>>
>>> because of doInsert is still true (I checked it) The cache is never
>>> checked for the object. doInsert is still true and
>>> a few lines later
>>>
>>> // now store it:
>>> store(obj, oid, cld, doInsert);
>>>
>>> generates the insert statement. Maybe I'm wrong but for me it looks
>>> like a 0 (not null) at any PK field causes a insert statement.
>>> In my case it is immediately the first object. Is it a good idea to
>>> check the cache independent if doInsert is true or is the
>>> implementation
>>> of representsNull the cause and should be changed ?
>>>
>>> best regards,
>>>
>>> Guido
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Armin Waibel <ar...@apache.org>.
Guido Beutler wrote:
> Hi,
>
> changing
>
> public boolean representsNull(FieldDescriptor fld, Object aValue)
> {
> .....
> if(((aValue instanceof Number) && (((Number) aValue).longValue()
> == 0)))
> {
> >>> result = fld.getPersistentField().getType().isPrimitive()
> && fld.isPrimaryKey();
> }
> ....
> return result;
> }
>
> into
>
> result = fld.getPersistentField().getType().isPrimitive() && !
> fld.isPrimaryKey();
> seems to fix my problem,
> updates are generated now and insert's work too.
> One of our OJB Guru's like Armin should take a look on it. ;-)
> I just made some small tests and can not be sure that this don't produce
> some side effects.
> If my fix is correct, updates never worked for objects with 0 values at
> primary key fields.
>
Maybe I'm on the wrong tack, but I don't figure out the change. This
method should return 'true'
- when the field as number of '0'
- and the field is primitive (short in your case)
- and the field-descriptor is declared as PK
In your patch you return true, when the field was not declared as PK.
But in that case all values are valid ('0' too). Your patch do the
opposite from what I expected. Maybe I'm completely confused ;-)
Again, if you have a class with primitive short field, declared as PK
with value '0', OJB assume that the field is nullified and because PK
couldn't be 'null' OJB assume the given object was new.
Hope I don't make a fool of oneself ;-)
regards,
Armin
> best regards,
>
> Guido
>
>
> Guido Beutler wrote:
>
>> Guido Beutler wrote:
>>
>>> Armin Waibel wrote:
>>>
>>>> do you use anonymous keys? If so where?
>>>>
>>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>>>> >> results?
>>>>
>>>> No, can you describe this problem again? Should I update to JBoss
>>>> 3.2.3 and run the tests again?
>>>
>>>
>>>
>>>
>>>
>>> we had the problem, that not all objects were returned by OJB. This
>>> seemed to be a side effect of the eager-release
>>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
>>> the bahavior of our current problem is different
>>> in 3.2.3.
>>> I'll put some debug gcode into PersistenceBroker and see what's going
>>> on during insert/update.
>>>
>>> best regards,
>>>
>>> Guido
>>
>>
>>
>> Hi,
>>
>> I added some debug code to
>>
>> PersistenceBrokerImpl :
>>
>> public void store(Object obj) throws PersistenceBrokerException
>> {
>>
>> ...
>>
>> boolean doInsert =
>> serviceBrokerHelper().hasNullPKField(cld, obj);
>>
>> returns true. The reason seems to be BrokerHelper.representsNull :
>>
>> public boolean representsNull(FieldDescriptor fld, Object aValue)
>> {
>> .....
>> if(((aValue instanceof Number) && (((Number)
>> aValue).longValue() == 0)))
>> {
>> result = fld.getPersistentField().getType().isPrimitive()
>> && fld.isPrimaryKey();
>> }
>> ....
>> return result;
>> }
>>
>> returns true for my SMALLINT objects if the value is 0. But 0 is a
>> leagal value for SMALLINT PK attributes.
>> After that PersistenceBrokerImpl.store checks the cache:
>>
>> /*
>> if PK values are set, lookup cache or db to see whether object
>> needs insert or update
>> */
>> if (!doInsert)
>> {
>> doInsert = objectCache.lookup(oid) == null
>> && !serviceBrokerHelper().doesExist(cld, oid, obj);
>> }
>>
>> because of doInsert is still true (I checked it) The cache is never
>> checked for the object. doInsert is still true and
>> a few lines later
>>
>> // now store it:
>> store(obj, oid, cld, doInsert);
>>
>> generates the insert statement. Maybe I'm wrong but for me it looks
>> like a 0 (not null) at any PK field causes a insert statement.
>> In my case it is immediately the first object. Is it a good idea to
>> check the cache independent if doInsert is true or is the implementation
>> of representsNull the cause and should be changed ?
>>
>> best regards,
>>
>> Guido
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Hi,
changing
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.....
if(((aValue instanceof Number) && (((Number) aValue).longValue()
== 0)))
{
>>> result = fld.getPersistentField().getType().isPrimitive()
&& fld.isPrimaryKey();
}
....
return result;
}
into
result = fld.getPersistentField().getType().isPrimitive() && !
fld.isPrimaryKey();
seems to fix my problem, updates are generated now and insert's work too.
One of our OJB Guru's like Armin should take a look on it. ;-)
I just made some small tests and can not be sure that this don't produce
some side effects.
If my fix is correct, updates never worked for objects with 0 values at
primary key fields.
best regards,
Guido
Guido Beutler wrote:
> Guido Beutler wrote:
>
>> Armin Waibel wrote:
>>
>>> do you use anonymous keys? If so where?
>>>
>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>>> >> results?
>>>
>>> No, can you describe this problem again? Should I update to JBoss
>>> 3.2.3 and run the tests again?
>>
>>
>>
>>
>> we had the problem, that not all objects were returned by OJB. This
>> seemed to be a side effect of the eager-release
>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
>> the bahavior of our current problem is different
>> in 3.2.3.
>> I'll put some debug gcode into PersistenceBroker and see what's going
>> on during insert/update.
>>
>> best regards,
>>
>> Guido
>
>
> Hi,
>
> I added some debug code to
>
> PersistenceBrokerImpl :
>
> public void store(Object obj) throws PersistenceBrokerException
> {
>
> ...
>
> boolean doInsert =
> serviceBrokerHelper().hasNullPKField(cld, obj);
>
> returns true. The reason seems to be BrokerHelper.representsNull :
>
> public boolean representsNull(FieldDescriptor fld, Object aValue)
> {
> .....
> if(((aValue instanceof Number) && (((Number)
> aValue).longValue() == 0)))
> {
> result = fld.getPersistentField().getType().isPrimitive()
> && fld.isPrimaryKey();
> }
> ....
> return result;
> }
>
> returns true for my SMALLINT objects if the value is 0. But 0 is a
> leagal value for SMALLINT PK attributes.
> After that PersistenceBrokerImpl.store checks the cache:
>
> /*
> if PK values are set, lookup cache or db to see whether object
> needs insert or update
> */
> if (!doInsert)
> {
> doInsert = objectCache.lookup(oid) == null
> && !serviceBrokerHelper().doesExist(cld, oid, obj);
> }
>
> because of doInsert is still true (I checked it) The cache is never
> checked for the object. doInsert is still true and
> a few lines later
>
> // now store it:
> store(obj, oid, cld, doInsert);
>
> generates the insert statement. Maybe I'm wrong but for me it looks
> like a 0 (not null) at any PK field causes a insert statement.
> In my case it is immediately the first object. Is it a good idea to
> check the cache independent if doInsert is true or is the implementation
> of representsNull the cause and should be changed ?
>
> best regards,
>
> Guido
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Armin Waibel <ar...@apache.org>.
Hi,
> returns true for my SMALLINT objects if the value is 0. But 0 is a
> leagal value for SMALLINT PK attributes.
Gotcha! Do you have declared the SMALLINT field as primitive field in
your object and declare this field as PK in class-descriptor? In that
case OJB assume the field represents 'null' (default value of primitive
number fields). OJB needs to represent a nullified field for primitive
fields, we take value '0' to do that job.
regards,
Armin
Guido Beutler wrote:
> Guido Beutler wrote:
>
>> Armin Waibel wrote:
>>
>>> do you use anonymous keys? If so where?
>>>
>>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>>> >> results?
>>>
>>> No, can you describe this problem again? Should I update to JBoss
>>> 3.2.3 and run the tests again?
>>
>>
>>
>>
>> we had the problem, that not all objects were returned by OJB. This
>> seemed to be a side effect of the eager-release
>> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
>> the bahavior of our current problem is different
>> in 3.2.3.
>> I'll put some debug gcode into PersistenceBroker and see what's going
>> on during insert/update.
>>
>> best regards,
>>
>> Guido
>
>
> Hi,
>
> I added some debug code to
>
> PersistenceBrokerImpl :
>
> public void store(Object obj) throws PersistenceBrokerException
> {
>
> ...
>
> boolean doInsert = serviceBrokerHelper().hasNullPKField(cld,
> obj);
>
> returns true. The reason seems to be BrokerHelper.representsNull :
>
> public boolean representsNull(FieldDescriptor fld, Object aValue)
> {
> .....
> if(((aValue instanceof Number) && (((Number) aValue).longValue()
> == 0)))
> {
> result = fld.getPersistentField().getType().isPrimitive() &&
> fld.isPrimaryKey();
> }
> ....
> return result;
> }
>
> returns true for my SMALLINT objects if the value is 0. But 0 is a
> leagal value for SMALLINT PK attributes.
> After that PersistenceBrokerImpl.store checks the cache:
>
> /*
> if PK values are set, lookup cache or db to see whether object
> needs insert or update
> */
> if (!doInsert)
> {
> doInsert = objectCache.lookup(oid) == null
> && !serviceBrokerHelper().doesExist(cld, oid, obj);
> }
>
> because of doInsert is still true (I checked it) The cache is never
> checked for the object. doInsert is still true and
> a few lines later
>
> // now store it:
> store(obj, oid, cld, doInsert);
>
> generates the insert statement. Maybe I'm wrong but for me it looks like
> a 0 (not null) at any PK field causes a insert statement.
> In my case it is immediately the first object. Is it a good idea to
> check the cache independent if doInsert is true or is the implementation
> of representsNull the cause and should be changed ?
>
> best regards,
>
> Guido
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Guido Beutler wrote:
> Armin Waibel wrote:
>
>> do you use anonymous keys? If so where?
>>
>> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>> >> results?
>>
>> No, can you describe this problem again? Should I update to JBoss
>> 3.2.3 and run the tests again?
>
>
>
> we had the problem, that not all objects were returned by OJB. This
> seemed to be a side effect of the eager-release
> flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that
> the bahavior of our current problem is different
> in 3.2.3.
> I'll put some debug gcode into PersistenceBroker and see what's going
> on during insert/update.
>
> best regards,
>
> Guido
Hi,
I added some debug code to
PersistenceBrokerImpl :
public void store(Object obj) throws PersistenceBrokerException
{
...
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld,
obj);
returns true. The reason seems to be BrokerHelper.representsNull :
public boolean representsNull(FieldDescriptor fld, Object aValue)
{
.....
if(((aValue instanceof Number) && (((Number) aValue).longValue()
== 0)))
{
result = fld.getPersistentField().getType().isPrimitive() &&
fld.isPrimaryKey();
}
....
return result;
}
returns true for my SMALLINT objects if the value is 0. But 0 is a
leagal value for SMALLINT PK attributes.
After that PersistenceBrokerImpl.store checks the cache:
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
because of doInsert is still true (I checked it) The cache is never
checked for the object. doInsert is still true and
a few lines later
// now store it:
store(obj, oid, cld, doInsert);
generates the insert statement. Maybe I'm wrong but for me it looks like
a 0 (not null) at any PK field causes a insert statement.
In my case it is immediately the first object. Is it a good idea to
check the cache independent if doInsert is true or is the implementation
of representsNull the cause and should be changed ?
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Armin Waibel wrote:
> do you use anonymous keys? If so where?
>
> >> Do you remember our DataSource problem with 3.2.2.RC3 with missing
> >> results?
>
> No, can you describe this problem again? Should I update to JBoss
> 3.2.3 and run the tests again?
we had the problem, that not all objects were returned by OJB. This
seemed to be a side effect of the eager-release
flag. After Update to JBoss 3.2.3 the problem disapeared. Maybe that the
bahavior of our current problem is different
in 3.2.3.
I'll put some debug gcode into PersistenceBroker and see what's going on
during insert/update.
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Armin Waibel <ar...@apache.org>.
do you use anonymous keys? If so where?
>> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>> results?
No, can you describe this problem again? Should I update to JBoss 3.2.3
and run the tests again?
Armin
Guido Beutler wrote:
> Hi again,
>
> Guido Beutler wrote:
>
>> Hi Armin,
>>
>> Armin Waibel wrote:
>>
>>> Hi again,
>>>
>>> all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and
>>> MaxDB. Maybe I forget to write a test for object update ;-).
>>>
>> Do you remember our DataSource problem with 3.2.2.RC3 with missing
>> results?
>> Maybe that the behavior is different to JBoss 3.2.3., just to have is
>> said. :-)
>>
>>> > Does ist help? I can not see your Methods at the stack trace. Is it
>>> > possible, that the cache is never checked?
>>> You can't see one of these methods in your stack trace, bacause these
>>> methods maybe generate a wrong value for boolean 'doInsert' in your
>>> case.
>>> The change made between rc5 to rc6 is a new check
>>> serviceBrokerHelper().hasNullPKField(cld, obj);
>>> and the
>>> deletedDuringTransaction.contains(oid);
>>> check. Is it possible that you pass a nullified PK field (declared in
>>> decriptor) when you update an object? In that case OJB try to insert
>>> the object.
>>>
>>> I think you have two possibilities:
>>> - remote debugging of this part of PBImpl class to see if a wrong
>>> boolean value was set - signals insert instead of update.
>>> - Put some System.out.println to check the boolean or/and comment out
>>> the new stuff and see what's going on.
>>
>>
>>
>>
>> I reduced my test to get some objects at a collection and store the
>> same objects again (without any modification).
>> The test immediately fails at the first insert. Because the select
>> returns the expected result and the objects are
>> returned by OJB I think I can be sure that the objects are filled
>> correctly.
>> I'll add some code to store the values before returning them to the
>> client but I don't think that this will make any difference.
>>
>
> If I select a collection by OJB and store ist at the same EJB Method
> (and transaction) a insert instead of update is generated.
> The PK Fields are filled correctly and are not modified during the test.
>
> best regards,
>
> Guido
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Hi again,
Guido Beutler wrote:
> Hi Armin,
>
> Armin Waibel wrote:
>
>> Hi again,
>>
>> all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and
>> MaxDB. Maybe I forget to write a test for object update ;-).
>>
> Do you remember our DataSource problem with 3.2.2.RC3 with missing
> results?
> Maybe that the behavior is different to JBoss 3.2.3., just to have is
> said. :-)
>
>> > Does ist help? I can not see your Methods at the stack trace. Is it
>> > possible, that the cache is never checked?
>> You can't see one of these methods in your stack trace, bacause these
>> methods maybe generate a wrong value for boolean 'doInsert' in your
>> case.
>> The change made between rc5 to rc6 is a new check
>> serviceBrokerHelper().hasNullPKField(cld, obj);
>> and the
>> deletedDuringTransaction.contains(oid);
>> check. Is it possible that you pass a nullified PK field (declared in
>> decriptor) when you update an object? In that case OJB try to insert
>> the object.
>>
>> I think you have two possibilities:
>> - remote debugging of this part of PBImpl class to see if a wrong
>> boolean value was set - signals insert instead of update.
>> - Put some System.out.println to check the boolean or/and comment out
>> the new stuff and see what's going on.
>
>
>
> I reduced my test to get some objects at a collection and store the
> same objects again (without any modification).
> The test immediately fails at the first insert. Because the select
> returns the expected result and the objects are
> returned by OJB I think I can be sure that the objects are filled
> correctly.
> I'll add some code to store the values before returning them to the
> client but I don't think that this will make any difference.
>
If I select a collection by OJB and store ist at the same EJB Method
(and transaction) a insert instead of update is generated.
The PK Fields are filled correctly and are not modified during the test.
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Hi Armin,
Armin Waibel wrote:
> Hi again,
>
> all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and
> MaxDB. Maybe I forget to write a test for object update ;-).
>
Do you remember our DataSource problem with 3.2.2.RC3 with missing results?
Maybe that the behavior is different to JBoss 3.2.3., just to have is
said. :-)
> > Does ist help? I can not see your Methods at the stack trace. Is it
> > possible, that the cache is never checked?
> You can't see one of these methods in your stack trace, bacause these
> methods maybe generate a wrong value for boolean 'doInsert' in your case.
> The change made between rc5 to rc6 is a new check
> serviceBrokerHelper().hasNullPKField(cld, obj);
> and the
> deletedDuringTransaction.contains(oid);
> check. Is it possible that you pass a nullified PK field (declared in
> decriptor) when you update an object? In that case OJB try to insert
> the object.
>
> I think you have two possibilities:
> - remote debugging of this part of PBImpl class to see if a wrong
> boolean value was set - signals insert instead of update.
> - Put some System.out.println to check the boolean or/and comment out
> the new stuff and see what's going on.
I reduced my test to get some objects at a collection and store the same
objects again (without any modification).
The test immediately fails at the first insert. Because the select
returns the expected result and the objects are
returned by OJB I think I can be sure that the objects are filled correctly.
I'll add some code to store the values before returning them to the
client but I don't think that this will make any difference.
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Armin Waibel <ar...@apache.org>.
Hi again,
all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and
MaxDB. Maybe I forget to write a test for object update ;-).
> Does ist help? I can not see your Methods at the stack trace. Is it
> possible, that the cache is never checked?
You can't see one of these methods in your stack trace, bacause these
methods maybe generate a wrong value for boolean 'doInsert' in your case.
The change made between rc5 to rc6 is a new check
serviceBrokerHelper().hasNullPKField(cld, obj);
and the
deletedDuringTransaction.contains(oid);
check. Is it possible that you pass a nullified PK field (declared in
decriptor) when you update an object? In that case OJB try to insert the
object.
I think you have two possibilities:
- remote debugging of this part of PBImpl class to see if a wrong
boolean value was set - signals insert instead of update.
- Put some System.out.println to check the boolean or/and comment out
the new stuff and see what's going on.
regards,
Armin
Guido Beutler wrote:
> Armin Waibel wrote:
>
>> Hi Guido,
>>
>> Guido Beutler wrote:
>>
>>> Hello,
>>>
>>> I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with
>>> DB2 V8.
>>> Since update to RC6 OJB generates a insert for every stored object
>>> when using PB API.
>>> OJB seems not to check if the object exists at database. If the
>>> object already exist,
>>> a SQL Exception is thrown. (-803 which means dublicated PK). If I try
>>> to insert the same object
>>> several times, every time the same exception is thrown. If I select
>>> the object first, OJB generates a insert too.
>>> I tried the same with RC5 (just to be sure that it is not a error at
>>> the test case) and RC5 works as expected.
>>> If the object exist a update is generated.
>>> Did I miss something or is it a new issue?
>>>
>>
>> hmm, in PBImpl we do:
>>
>> ClassDescriptor cld = getClassDescriptor(obj.getClass());
>> /*
>> if one of the PK fields was null, the objects was new
>> and needs insert
>> */
>> boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
>> //if one of the PK field represents 'null' OJB assume the object is new
>> Identity oid = new Identity(obj, this, cld);
>>
>> /*
>> if the object has been deleted during this transaction,
>> then we must insert it
>> */
>> boolean shouldRemoveFromDeleted = false;
>> if (!doInsert)
>> {
>> doInsert = deletedDuringTransaction.contains(oid);
>> shouldRemoveFromDeleted = true;
>> }
>>
>> /*
>> if PK values are set, lookup cache or db to see whether object
>> needs insert or update
>> */
>> if (!doInsert)
>> {
>> doInsert = objectCache.lookup(oid) == null
>> && !serviceBrokerHelper().doesExist(cld, oid, obj);
>> }
>> // now store it:
>> store(obj, oid, cld, doInsert);
>>
>> Which of these methods returns a wrong result?
>>
>> regards,
>> Armin
>>
> Hi Armin, :-)
>
> that's the stacktrace:
>
> org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while
> insert object data for class
> ...
> at
> org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242)
>
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620)
>
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537)
>
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683)
>
> at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
>
> at
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
>
>
> And here's the Cache related stuff from ojb.properties:
>
> #----------------------------------------------------------------------------------------
>
> # Object cache
> #----------------------------------------------------------------------------------------
>
> # The ObjectCacheClass entry tells OJB which concrete ObjectCache
> # implementation is to be used as standard cache.
> # Its also possible to override this entry adding object-cache elements
> # on jdbc-connection-descriptor level and
> # per class-descriptor in repository file. More info see documentation.
> #
> ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
> #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
> #
> #
> # This property is only relevant if the per class-descriptor object-cache
> # declaration was used in conjunction with metadata runtime changes.
> # If set 'flase' the class name of the object is used
> # to find a per class ObjectCache implementation.
> # If set 'true' the ObjectCacheDescriptor instance is used as key to
> # find a per class ObjectCache, this enables to use different ObjectCache
> # instances for the same class.
> descriptorBasedCaches=false
> #
> #
> # Use CacheFilters to do filter operations before caching methods were
> # called. Build your own filter class by implementing
> org.apache.ojb.cache.CacheFilter.
> # It is possible to use a arbitrary number of CacheFilters, but this slows
> # down the performance of the cache, thus handle with care.
> #
> # - org.apache.ojb.broker.cache.CacheFilterClassImpl
> # allows filtering of classes
> # - org.apache.ojb.broker.cache.CacheFilterPackageImpl
> # allows filtering of packages
> # More info see Javadoc of the according classes.
> # Set a comma separated list of CacheFilter.
> #ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
>
> #
>
> Does ist help? I can not see your Methods at the stack trace. Is it
> possible, that the cache is never checked?
>
> best regards,
>
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Guido Beutler <gu...@hrs.de>.
Armin Waibel wrote:
> Hi Guido,
>
> Guido Beutler wrote:
>
>> Hello,
>>
>> I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with
>> DB2 V8.
>> Since update to RC6 OJB generates a insert for every stored object
>> when using PB API.
>> OJB seems not to check if the object exists at database. If the
>> object already exist,
>> a SQL Exception is thrown. (-803 which means dublicated PK). If I try
>> to insert the same object
>> several times, every time the same exception is thrown. If I select
>> the object first, OJB generates a insert too.
>> I tried the same with RC5 (just to be sure that it is not a error at
>> the test case) and RC5 works as expected.
>> If the object exist a update is generated.
>> Did I miss something or is it a new issue?
>>
>
> hmm, in PBImpl we do:
>
> ClassDescriptor cld = getClassDescriptor(obj.getClass());
> /*
> if one of the PK fields was null, the objects was new
> and needs insert
> */
> boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
> //if one of the PK field represents 'null' OJB assume the object is new
> Identity oid = new Identity(obj, this, cld);
>
> /*
> if the object has been deleted during this transaction,
> then we must insert it
> */
> boolean shouldRemoveFromDeleted = false;
> if (!doInsert)
> {
> doInsert = deletedDuringTransaction.contains(oid);
> shouldRemoveFromDeleted = true;
> }
>
> /*
> if PK values are set, lookup cache or db to see whether object
> needs insert or update
> */
> if (!doInsert)
> {
> doInsert = objectCache.lookup(oid) == null
> && !serviceBrokerHelper().doesExist(cld, oid, obj);
> }
> // now store it:
> store(obj, oid, cld, doInsert);
>
> Which of these methods returns a wrong result?
>
> regards,
> Armin
>
Hi Armin, :-)
that's the stacktrace:
org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while
insert object data for class
...
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174)
And here's the Cache related stuff from ojb.properties:
#----------------------------------------------------------------------------------------
# Object cache
#----------------------------------------------------------------------------------------
# The ObjectCacheClass entry tells OJB which concrete ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per class-descriptor object-cache
# declaration was used in conjunction with metadata runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is used as key to
# find a per class ObjectCache, this enables to use different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before caching methods were
# called. Build your own filter class by implementing
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of CacheFilters, but this slows
# down the performance of the cache, thus handle with care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl
#
Does ist help? I can not see your Methods at the stack trace. Is it
possible, that the cache is never checked?
best regards,
Guido
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Insert instead of update generated in RC6
Posted by Armin Waibel <ar...@apache.org>.
Hi Guido,
Guido Beutler wrote:
> Hello,
>
> I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with DB2
> V8.
> Since update to RC6 OJB generates a insert for every stored object when
> using PB API.
> OJB seems not to check if the object exists at database. If the object
> already exist,
> a SQL Exception is thrown. (-803 which means dublicated PK). If I try to
> insert the same object
> several times, every time the same exception is thrown. If I select the
> object first, OJB generates a insert too.
> I tried the same with RC5 (just to be sure that it is not a error at the
> test case) and RC5 works as expected.
> If the object exist a update is generated.
> Did I miss something or is it a new issue?
>
hmm, in PBImpl we do:
ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
doInsert = deletedDuringTransaction.contains(oid);
shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
doInsert = objectCache.lookup(oid) == null
&& !serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?
regards,
Armin
> best regards,
>
> Guido
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org