Hi Guenther,

I improved the javadoc comment in PersistenceBroker#deleteByQuery.

regards,
Armin

Guenther Wieser wrote:
hi armin,

thanks for your answer. just started using OJB and i like the documentation
very much (and of course OJB itself, too ;-) ).
may i propose to add some information to the docs regarding the fact that
OJB won't handle relations if one uses deleteByQuery? i think this will also
happen for 1:1 and 1:n relation, too.

kr,
guenther


-----Urspr�ngliche Nachricht----- Von: Armin Waibel [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 17. Februar 2005 22:42 An: OJB Users List Betreff: Re: AW: problem with m:n relation to some class


Hi G�nther,

Guenther Wieser wrote:

hi,

i finally found some sort of "solution" for this problem:

what i did in my code so far was calling
PersistenceBroker.deleteByQuery(Query).
this cause the mentioned problems.
now i tried to use PersistenceBroker.delete(Object) and using this, the
relations have been removed from the indirection table, too.
this fixes my problem so far, but is that an expected behaviour for
non-decomposed m:n-realtions?



yep, using PB.deleteByQuery(...) could be problematic, because it only
performs the specified sql-query nothing more (ignores cache, ignores
relationships,...).

You can configure the "delete behavior" of references when deleting the
main object by the auto-delete settings. If you set auto-delete 'OBJECT'
the entries in the indirection table and all references should be
deleted. If you set 'LINK' only the main object and the indirection
entries should be deleted. If you set 'NONE' you have to "unlink" the
references by hand, see
http://db.apache.org/ojb/docu/guides/basic-technique.html#Link+references

There is a big test case showing all cases in OJB test suite
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/test/org/apache/ojb/broker/M2NT
est.java?view=markup

regards,
Armin



kr,

G�nther Wieser

creative-it
Guglgasse 6/1/11/1
A-1110 Wien
Austria
http://www.creative-it.com



-----Urspr�ngliche Nachricht-----
Von: Guenther Wieser [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 16. Februar 2005 21:25
An: [email protected]
Betreff: **SPAM** problem with m:n relation to some class


hi,

i'm using ojb 1.0.1, and i need to implement a m:n relation ship from
objects of one class to objects of the same class.
before you complain that this is strange and can lead to circular
referencens, let me explain: i know that, but i need to implement this.
reason is: we want to use enhydra shark, a workflow engine, and it relies

on

the capability of the data model that it can nest groups into groups, this
way building a hierarchy of groups.
here's the excerpt from repository.xml:

        <class-descriptor
                class="com.creative_it.webcreator.model.usergroup.Group"
                table="grouptable">
                <field-descriptor id="1" name="id" column="id"
                        jdbc-type="BIGINT" primarykey="true" autoincrement="true" 
/>
                <field-descriptor id="2" name="groupid" column="groupid"
                        jdbc-type="VARCHAR" />
                <field-descriptor id="3" name="description" column="description"
                        jdbc-type="VARCHAR" />
                <collection-descriptor name="users"


collection-class="org.apache.ojb.broker.util.collections.ManageableArrayL

ist"
                        
element-class-ref="com.creative_it.webcreator.model.usergroup.User"
                        auto-retrieve="true" auto-update="link" 
auto-delete="link"
                        indirection-table="usergrouptable">
                        <fk-pointing-to-this-class column="groupid" />
                        <fk-pointing-to-element-class column="userid" />
                </collection-descriptor>
                <collection-descriptor name="subGroups"


collection-class="org.apache.ojb.broker.util.collections.ManageableArrayL

ist"
                        
element-class-ref="com.creative_it.webcreator.model.usergroup.Group"
                        auto-retrieve="true" auto-update="false" 
auto-delete="false"
                        indirection-table="groupgrouptable">
                        <fk-pointing-to-this-class column="groupid" />
                        <fk-pointing-to-element-class column="sub_gid" />
                </collection-descriptor>
                <collection-descriptor name="parentGroups"


collection-class="org.apache.ojb.broker.util.collections.ManageableArrayL

ist"
                        
element-class-ref="com.creative_it.webcreator.model.usergroup.Group"
                        auto-retrieve="true" auto-update="false" 
auto-delete="false"
                        indirection-table="groupgrouptable">
                        <fk-pointing-to-this-class column="sub_gid" />
                        <fk-pointing-to-element-class column="groupid" />
                </collection-descriptor>
        </class-descriptor>

my problem in detail is, that everything works fine when it comes to
creation and update, but when i delete a group, the entries in the
indirection table are not deleted. i tried all possibilities of

auto-delete

and auto-update, so don't bother the "false" in this excerpt.

by the way, the user-group-relation (which is also a non-decomposed m:n
relation) works perfect, so i'm quite sure this is just a problem of
referencing the same class....

any idea how to solve this problem?

kr,
guenther



---------------------------------------------------------------------
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]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to