Re: [Jaxor-devel] Re: Associating Lists

[Michael R. <mik...@ya...>]

Yes, it can be complicated. I guess I haven't
implemented anything b/c I haven't run across
situations where it was difficult to manage manually.
The code to manually update fields is trivial. Though
transparency has benefits too. Don't worry about
changing the DTD. Just change it so the new element or
attribute is not required and defaults to the current
implementation. I think adding an element or attribute
is the only way that this will ever work correctly. It
cannot always be automatic. There are always
exceptions. Certainly, we need an attribute to turn
off automatic relationship management. 

Your example seems sensible, but would make more sense
to me with some unit tests. Do you have a use case
from an app you are currently writing? I usually
create a unit test that satisfies the requirements of
an app I'm working on in the simplest manner possible.
Then change the code to meet those requirements. 

Regards,

Mike

--- Carl Fyffe <car...@gm...> wrote:

> I think I see why you have avoided this for so
> long... it is hard to
> know exactly what the user is going to want without
> resorting to the
> verbose hibernate style dtd. I am trying to avoid
> changing the DTD at
> all costs and trying to use the api as it exists to
> achieve the
> results we are looking for. The main problem I
> continue to run into is
> that of id generation and other things of that
> nature (filling in
> details of a linking table that don't neccessarily
> have anything to do
> with the links).
> 
> Forgetting about the linking table details I would
> like to throw a
> theory out there.  Please tell me if this holds
> water.
> 
> 
> 
> If there are entity ref's to multiple tables, the
> host table can be
> thought of as a many to many linking table of some
> kind.
> 
> IE groupmembers has two entity ref's, one to groups,
> one to users.
> This means jaxor should generate a
> newInstances(group, userList) and a
> newInstances(user, groupList) method in the Finder.
> This is the easy
> case.
> 
> Now, lets look at adding a third entity ref.  I
> couldn't figure out a
> sensible way to model this with users and groups so
> I am gonna go with
> the structure of XML.  Say we wanted to create a
> generic way to store
> XML in an RDBMS. We would have tables for documents,
> elements and
> attributes. If this was normalized we would only
> want one instance for
> each element and attribute. So if we go all the way
> down to the
> instance of an attribute we would have something
> like this:
> 
> <jaxor
> package="net.sourceforge.jaxor.example.xml.jaxor">
>     <entity name="attribute_instance"
> alias="AttributeInstance" >
>         <primary-key>
>             <column name="attribute_instance_id"
> type="Long"/>
>         </primary-key>
>         <column name="element_instance_id"
> type="Long"/>
>         <column name="attribute_id" type="Long"/>
>         <column name="document_id" type="Long"/>
> 
>         <entity-ref table="element_instance">
>             <key source="element_instance_id"
> target="element_instance_id"/>
>         </entity-ref>
>         <entity-ref table="attribute">
>             <key source="attribute_id"
> target="attribute_id"/>
>         </entity-ref>
>         <entity-ref table="document">
>             <key source="document_id"
> target="document_id"/>
>         </entity-ref>
> 
>     </entity>
> </jaxor>
> 
> The attribute instance points to a singular element
> instance, which in
> turns points to a concrete element. The attribute
> instance also points
> to a concrete attribute and document.
> 
> In this case, we would want jaxor to generate a
> bunch of
> newInstances() methods....  We are only going to
> want three:
> 
> newInstances(document, attribute,
> elementInstanceList)
> newInstances(document, attributeList,
> elementInstance)
> newInstances(documentList, attribute,
> elementInstance)
> 
> I don't think it really makes sense to pass in more
> than one List.
> 
> Of course it is completely plausible to have a List
> of groups and a
> List of users and you want to put all of the users
> into all of the
> groups, but does that hold true when you have more
> than two
> references?
> 
> newInstances(documentList, attribute,
> elementInstance)
> newInstances(document, attributeList,
> elementInstance)
> newInstances(document, attribute,
> elementInstanceList)
> 
> newInstances(document, attributeList,
> elementInstanceList)
> newInstances(documentList, attribute,
> elementInstanceList)
> 
> newInstances(documentList, attributeList,
> elementInstance)
> 
> newInstances(documentList, attributeList,
> elementInstanceList)
> 
> The matrix only grows if we add another entity ref.
> Not to mention we
> still don't have a way to fill in the id's of all of
> the rows that
> will be created...
> 
> Does this make sense, and should I move forward with
> this strategy?
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail