On Mon, 2002-09-09 at 13:22, Stephen Haberman wrote: > > > 1 - Data Model Relationships > > defining foreign-key-like relationships in the object model that > are > > not existant or created in the database. What I want is for the OM > > access methods to be generated for this type of access, even if it > > does not explicitly exist in the database as a fk. > > I like the schema being as close to the database as possible, so I'd be > against adding any extra generation information. This is what the > extension classes are for. > > Generally if you're going to do this type of stuff, it's good database > design to use a fk anyway.
Two reasons we cant use a FK - legacy database that I cannot alter, and a "circular" fk! My problem is one of the selling points of Torque will be to generate as much repetative or design level code as possible, allowing us to concentrate on the "business" coding. I understand the use of the extension classes, but I want as little hand coding as possible - we have lots of pieces of code that will repeat in all of our objects, that I dont really want to hand code over and over. I know I can just "enhance" torque for my own uses and keep it private, but I would like to provide anything I come up with usefull to the community as well - maby if we can come up with a flexable torque extension method it could help? Perhaps what Torque needs is a seperate database-schema.xml and db-om-mapping.xml that would seperate the db and om code? I realize this is not a v3 thing, but would something like this make sense? I would think it almost necessary if the possiblity of becoming OJB's forward-reverse tool becomes more likely. > > > 2 - "javaName" attribute for relationships (FK and above) > > providing a "javaName" attribute to foreign-key (and the above > > mentioned relationships) to allow control of the generated > accessor > > method names: > > I like this idea. The javaName pollutes the db-only schema, but we > already use it extensively in the rest of the schema. What to entire a > feature request for it into http://scarab.werken.com:8080/issues? will do. > > - Stephen > > > > -- > 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]>
