Dear Bill, We have tested using BC4J which uses Oracle JDBC driver behind the scenes, and we saved BLOBS no problem with a size aprox. greater than 15k. !! I am a little suprised !!
regards Ben ----- Original Message ----- From: "Bill Leng" <[EMAIL PROTECTED]> To: "Apache Torque Users List" <[EMAIL PROTECTED]> Sent: Monday, August 04, 2003 8:02 PM Subject: Re: Toruqe supports BLOB ???? > Add to Geoff's comment. It is confirmed that it works with datadirect's > jdbc driver for Oracle. Oracle's thin jdbc driver does not work. > > Geoff Fortytwo wrote: > > > If you're using oracle than it isn't possible to use blobs with torque. > > (except possibly if you use a driver that's not from Oracle. but that > > isn't confirmed) > > > > At 10:40 AM 8/4/2003, you wrote: > > > >> 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] > > -- > Bill Leng > Metatomix, Inc. > Tel: (901)261-8911 > Fax: (901)261-8901 > > > --------------------------------------------------------------------- > 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]
