Dear List and Torque Developers, Not much activity on this list is there?? :)
The http://db.apache.org/torque/dtd/database_3_1.dtd indicates that BLOB are a valid torque data type. It possible to save an image to a blob with the current version ? Could someone give a small example. We have done this using BC4J and with JDBC on its own, does the current version of torque help me? Kind regards, Ben bookey. ----- Original Message ----- From: "Michel Beijlevelt / Lucka" <[EMAIL PROTECTED]> To: "Apache Torque Users List" <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 2:42 PM Subject: Re: different internal variable names > Howdy, > > the opinion about tight or loose coupling is also influenced by the > frequency of changes in the RDBMS schema. > > If my application is - through Torque - tightly coupled with the RDBMS, > it will almost certainly fail with an exception upon a moderately > significant change in the RDBMS. Which is good, because it will > precisely pinpoint the change, and makes 'sure' (well, fairly sure that > is :-) that my appliction only runs against the RDBMS that is was > designed for and none other. > > But I agree, having the possibility of making Torque more loosely > coupled from the RDBMS would be a nice feature. It could be implemented > by allowing specifying aliases for db objects in the XML schema > definition which does seem to be fairly simple to implement, but maybe a > more sophisticated abstraction layer isn't that hard to make either. > > gr. Michel > > > Manske, Michael wrote: > > >hi, > > > >i knew that such a discussion would come up and it depends on the point of > >view of each indivual user. :) > > > > > > > >>I don't know, I think I would Torque rather see more tightly coupled > >>with the RDBMS and dump the XML schema entirely. > >> > >> > >if you have control over database structure and changes of the database > >structure, then you will > >perhaps prefer a strict coupling. But if not (like me), you will always > >prefer loose coupling to be more independent of changes made by another dev > >team. > > > > > > > >>My RDBMS already has a schema, which would be the metadatabase in the > >>systems tables. So why create another definition in XML of the same > >>database and tables? > >> > >> > >If you have to support different RDBMS the metadescription in some "system > >tables" will get useless. > > > > > > > >>Torque's capability of abstraction of the RDBMS-specific > >>isssues comes > >>in quite handy here. The process could be automated by having Torque > >>generate the XML definition from a JDBC conncection, and then > >>generate > >>the om from that XML, but I haven't tried that yet. > >> > >> > >Thats what i'm talking about, we are working with torque this way because we > >have to deal > >with a couple of already existing databases. > >And yes, torques abstraction is somewhat of handy - thats why we use it. :-) > > > >Loose coupling means among other things to hide the physical database > >structure completely from the objects, which have to access the database. A > >layer (like torque) will then act as mediator between objects and database. > >So if you would have problematic identifiers like "short", you would be > >easily able to map them to another name, which could then be used in java > >objects, e.g. map "short" to "short_descr". > >There is already some kind of support for this but at the moment it isn't > >suitable at all. > > > >I guess torque is so popular because of his abilities to generate more or > >less useable code and the usage of a xml schema at runtime (respectively at > >application startup) would possibly be contradictory to the generator BUT it > >would also provide more independency from used database structure. > > > >I'm not sure wheter this is a mainly intention of torque but i would be glad > >if the devs would expand > >support for loose coupling (at least for mapping of table/column names to > >java names) in future versions... > > > >regards, > >Michael > > > >PS: pros and cons of loose coupling will always be a matter of opinion > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
