-----Original Message-----
From: John McNally [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 3:35 PM
To: Turbine Users List
Subject: Re: Suggestions for torque
"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?
------------------------------------------------------------------------
What if my table doesn't have the deleted column or anything else except the
foreign keys (which is a primary key). This suggestion follows the 80/20
rule. If you added additional columns, you can not call it n:m mapping but
instead you call it 1:m and m:1 mapping.
>
>
> 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?
---------------------------------------------------------------------
I just don't want to onverts key object to java data type on every instance.
And this can be done easily...it should be similar to EJB in concept.
>
>
> 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.)
---------------------------------------------------------------------
I am talking about the "Base" and "Peer" extension...it should be
Flexible enough to allow the user the specify anything that they want...for
example by defaul:
basePrefix = "Base"
basSuffix = ""
peerPrefix = ""
peerSuffix = "Peer"
Custom:
basePrefix = ""
basSuffix = "Impl"
peerPrefix = "DAO"
peerSuffix = ""
...just an example.
>
>
> 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.
---------------------------------------------------------------------
I am not taking about the merging the security model to the o/r mapping
layer. I was talking about the improving the security model in general.
I will write a separated email regarding the security model design...
john mcnally
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
