you can fix this by simply grabbing the latest village jar from http://www.ibiblio.org/maven/village/jars

martin

Joachim M�ller wrote:

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]



Reply via email to