----- Original Message ----- From: "Joachim Müller" <[EMAIL PROTECTED]> To: "Apache Torque Users List" <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 7:55 PM Subject: AW: Toruqe supports BLOB ????
> > Hi Ben. > > I do use CLOBs with oracle but had to apply a patch to > do so. I think I read in the mailing list that the current > CVS version has this fix already. > > actually it's in village, not in torque. > > If you do not have an solution yet, contact me. > > > regards from frankfurt. > > joachim/wemove > > > > -----Ursprüngliche Nachricht----- > > Von: BEN BOOKEY [mailto:[EMAIL PROTECTED] > > Gesendet: Montag, 4. August 2003 19:41 > > An: Apache Torque Users List > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Betreff: Toruqe supports BLOB ???? > > > > > > 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] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
