Hi Tim,

I believe the bug you found was fixed two weeks or more ago, isn't it?




Thomas

-----Original Message-----
>From: Tim Fox [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 17, 2001 6:37 AM
>To: [EMAIL PROTECTED]
>Subject: [castor-dev] Possible bug(?) in many-many relation - setting
collection with too many objects
>
>I have what looks like a bug (although it's probably just my stupidity) in
>many-many relations:
>
>I have a Product class, and a Category class - a Product can be in many
>Categories, a Category can contain many products.
>
>I have a many-many link table in my db, normal kind of thing just
containing
>productid and categoryid.
>
>Here are my Product and Category classes (cut down for clarity)
>
>public class Category
>{
>    private long _id;
>    private String _name;
>
>    public void setId(long id) { _id = id; }
>    public void setName(String name) { _name = name; }
>    public long getId() { return _id; }
>    public String getName() { return _name; }
>}
>
>public class Product
>{
>    private long _id;
>    private String _sku;
>    private String _name;
>    private Collection _categories;
>
>    public void setId(long id) { _id = id; }
>    public void setSku(String sku) { _sku = sku; }
>    public void setName(String name) { _name = name; }
>    public void setCategories(Collection categories) { _categories =
>categories; }
>    public long getId() { return _id; }
>    public String getSku() { return _sku; }
>    public String getName() { return _name; }
>    public Collection getCategories() { return _categories; }
>}
>
>Here are the class mappings for Product and Category from my mapping file:
>
><class name="com.blueheath.mercury.om.Product" identity="id"
>key-generator="prod_seq">
>        <description>Product object mapping</description>
>        <map-to table="product"/>
>        <field name="id" type="long">
>                <sql name="id" type="numeric"/>
>        </field>
>        <field name="sku" type="string">
>                <sql name="sku" type="varchar"/>
>        </field>
>        <field name="name" type="string">
>                <sql name="name" type="varchar"/>
>        </field>
>        <field name="categories" type="com.blueheath.mercury.om.Category"
>collection="collection" >
>                <sql name="categoryid" many-table="productcategory"
many-key="productid"
>/>
>        </field>
></class>
>
><class name="com.blueheath.mercury.om.Category" identity="id"
>key-generator="category_seq">
>        <description>Category object mapping</description>
>        <map-to table="category"/>
>        <field name="id" type="long">
>                <sql name="id" type="numeric"/>
>        </field>
>        <field name="name" type="string">
>                <sql name="name" type="varchar"/>
>        </field>
></class>
>
>
>Here's the weirdness.
>When I use the following to load some products
>
>String sq = "SELECT p from com.blueheath.mercury.om.Product p";
>OQLQuery q = db.getOQLQuery(sq);
>QueryResults res = q.execute();
>while (res.hasMore())
>{
>        Product p = (Product)res.next();
>      System.out.println("THE SIZE IS " + p.getCategories().size());
>}
>
>I get the following on stdout:
>
>THE SIZE IS 1
>THE SIZE IS 2
>THE SIZE IS 3
>THE SIZE IS 4
>THE SIZE IS 5
>all the way up to...
>THE SIZE IS 125
>
>BUT! Each of my products is only associated with one category!!
>(This can be clearly seen in the many-many table as there's only one row
for
>each product in that table, please trust me on this one - this is not a
data
>error!)
>It seems as if the collection used in the Castor code to call
>Product.setCategories(Collection categories) is not being cleared out
>between invocations. (Or something like that)
>I can see this more clearly by putting some trace code in the
>Product.setCategories(Collection categories) method. Again I see the
>collection this method is called with incrementally gets bigger between
>invocations.
>I have looked at the Castor code, but have not had time to go into it too
>deeply, although if no-one has seen this before/has any ideas then I shall
>do so.
>BTW I have tried both lazy and non-lazy loading and get the same effect.
>
>TIA
>Tim Fox
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
>        unsubscribe castor-dev
>

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to