"Hoang, Hai" wrote: > > Problem 1: How do I specify a unidirectional between two tables? > > > > Solution: add the unidirectional="true" attribute to the <foreign-key> tag > > > > Problem 2: How do you map many-to-many between table such as user and group > map to user_group without having torque create the classes for the > user_group table? > > > > Solution: Specify joint-table="true" in the <foreign-key> tag in the user > and group tables >
What does this gain us? What do you do if the user_group table has a DELETED column? > > > The implementation of the above problems should be at least like the > relationship in EJB CMP 2.0 > > > > Problem 3: How do you separate the business object and business object > manager into separate classes so that your object model increases decoupling > between interface and implementation? Currently, BaseXYZ.jave contains both > the business object functionality such as getter/setter and business object > manager functionality such as save, update, delete, etc... > I could see moving the save method to the manager class, as managers have just been added it was not possible before. Anyone see advantages to leaving the save method within the bo? > > > Solution: The BaseImpl.java class should contain only the getter and setter > for the business object and nothing else... and it should be implementing > the Base.java interface. In addition, the BaseImplManager.jave should have > all the manager functionalities and it should be implementing the > BaseManager.java interface > > > > Problem 4: If a table contains only a single primary field then the > Base.java classes should return the actual java data type such as Long or > String and not NumberKey or StringKey or anything else on the primary field. > So you want Managers to have methods like getInstance(Object)? I prefer a specific class/interface for oid's. Why do you see this as a problem? > > > Problem 5: Torque should allow the user the specify the naming convention > and data type conversion somewhere so that the user can be pick and > choose... > I believe this already exists, jdbc has guidelines for conversion between jdbc types and native java types, but you can map jdbc types to native db types to get the effect you desire. You can also specify the class responsible for name conversions (though I have never modified this, so maybe it is not as easy as I think.) > > > Also, the current security model needs to change and I am in a process of > doing that. I would love to see what you've out there for the proposed > functionalities before I go ahead with my implementation. > The current security model of keeping security concerns out of the o/r mapping layer? It would be interesting to hear your thoughts on this, but you should get some confirmation of your design before wasting time implementing something that will not be acceptable. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
