Issue with Reference Descriptors and ForeignKey Field Refs

[Leigh Estes <le...@digitalchocolate.com>]

We have found an interesting behavior that has only cropped up since we
updated from OJB 1.0.2 to 1.0.3. We have an object mapping defined as
follows:

<class-descriptor class="com.dchoc.sphinx.entity.QuestionEntity"
table="QUESTIONS">
    <field-descriptor id="1" name="id" column="ID" jdbc-type="INTEGER"
primarykey="true"
     autoincrement="true" />
    <field-descriptor id="2" name="batchId" column="BATCH_ID"
jdbc-type="INTEGER" />
    <field-descriptor id="4" name="title" column="TITLE"
jdbc-type="VARCHAR" />
    <field-descriptor id="5" name="text" column="TEXT" jdbc-type="VARCHAR" />
	<reference-descriptor name="batch"
		 class-ref="com.dchoc.sphinx.entity.BatchEntity">
		 <foreignkey field-ref="batchId"/>
	</reference-descriptor>
</class-descriptor>

First, using PersistenceBroker.store(obj), we create a question object in
the database that has a batch ID set, but whose batch member variable is
null. In this case, the row in the QUESTIONS table is created properly
with the appropriate BATCH_ID value. However, if we then update this same
question object using PersistenceBroker.store(obj,
ObjectModificationDefaultImpl.UPDATE), the batch ID in the object and the
database is updated to 0 - presumably because the batch reference in the
object was null (I should mention that the batch ID referenced in the
batch ID member variable does exist in the database). As mentioned, this
has only started happening since OJB 1.0.3. In 1.0.2, if the batch
reference was null, the batch ID was left alone. Presumably, the older
version did the more appropriate thing and left the member
variable/database value associated with the foriegnkey field-ref alone if
the reference-descriptor was null. Why does the more current version set
the value to 0 and save it to the database in this case? Is there some
reason it has to work this way? The old behavior seemed a lot more
friendly. With the new behavior, after creating the question, we have to
hit the database again to look it up via a persistence broker so that the
reference descriptor object will be filled in and our ID won't be reset to
0 if we do anymore updates on the question object.

Thanks,
Leigh



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

Re: Issue with Reference Descriptors and ForeignKey Field Refs

[Armin Waibel <ar...@apache.org>]

Hi Leigh,

Leigh Estes wrote:
> We have found an interesting behavior that has only cropped up since we
> updated from OJB 1.0.2 to 1.0.3. We have an object mapping defined as
> follows:
> 
> <class-descriptor class="com.dchoc.sphinx.entity.QuestionEntity"
> table="QUESTIONS">
>     <field-descriptor id="1" name="id" column="ID" jdbc-type="INTEGER"
> primarykey="true"
>      autoincrement="true" />
>     <field-descriptor id="2" name="batchId" column="BATCH_ID"
> jdbc-type="INTEGER" />
>     <field-descriptor id="4" name="title" column="TITLE"
> jdbc-type="VARCHAR" />
>     <field-descriptor id="5" name="text" column="TEXT" jdbc-type="VARCHAR" />
> 	<reference-descriptor name="batch"
> 		 class-ref="com.dchoc.sphinx.entity.BatchEntity">
> 		 <foreignkey field-ref="batchId"/>
> 	</reference-descriptor>
> </class-descriptor>
> 
> First, using PersistenceBroker.store(obj), we create a question object in
> the database that has a batch ID set, but whose batch member variable is
> null. In this case, the row in the QUESTIONS table is created properly
> with the appropriate BATCH_ID value. However, if we then update this same
> question object using PersistenceBroker.store(obj,
> ObjectModificationDefaultImpl.UPDATE), the batch ID in the object and the
> database is updated to 0 - presumably because the batch reference in the
> object was null (I should mention that the batch ID referenced in the
> batch ID member variable does exist in the database). As mentioned, this
> has only started happening since OJB 1.0.3. In 1.0.2, if the batch
> reference was null, the batch ID was left alone. Presumably, the older
> version did the more appropriate thing and left the member
> variable/database value associated with the foriegnkey field-ref alone if
> the reference-descriptor was null. Why does the more current version set
> the value to 0 and save it to the database in this case? Is there some
> reason it has to work this way? 

You don't specify any auto-xxx settings in this case (if the 
repository.dtd can be found) OJB use the following settings:
auto-retrieve true
auto-update false -> same as 'link'
auto-delete false -> same as 'object'
http://db.apache.org/ojb/docu/guides/basic-technique.html#1%3A1+auto-xxx+setting

When using auto-update 'link' OJB always check for the referenced object 
and if not set the FK will be nullified (except on main object insert, 
then it's allowed to populate the FK without referenced object).
This behavior is needed, because it's the only way for the PB-api to 
detect deleted references.

If you completely control the association/deletion of the 1:1 reference 
by yourself, set auto-update/delete to 'none'. In this case OJB 
will/(should) not touch the FK of the main object.

regards,
Armin


> The old behavior seemed a lot more
> friendly. With the new behavior, after creating the question, we have to
> hit the database again to look it up via a persistence broker so that the
> reference descriptor object will be filled in and our ID won't be reset to
> 0 if we do anymore updates on the question object.
> 
> Thanks,
> Leigh
> 
> 
> 
> ---------------------------------------------------------------------
> 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