Re: Subproject Proposal - crossdb
From: Peter Donald [EMAIL PROTECTED] Sou you end up with something like following in torque MyData (The Biz Object) MyDataVO (The Value Object) MyDataPeer (The Peer) AbstractMyData (the abstract biz object) AbstractMyDataPeer (The abstract Peer) And the only one decoupled from the persistence framework is MyDataVO. In an ideal situation you would just have a single object MyData that is free from persistence framework and is nice and simple. (and basically a clone of MyDataVO). The rest of the stuff could be dynamically configured at runtime - including the mapping to physical datasource. Any system that did that and did not have all the rest of the cruft would be a sure winner IMHO. Agreed. I've wondered a few times if maybe Torque could be patched so that in addition it could work with DyanBeans as an alternative to code generation. Then at runtime Torque could just work given some regular beans (MyData) or even just figure out its own DynaBeans based on the database schema. http://nagoya.apache.org/gump/javadoc/jakarta-commons/beanutils/dist/docs/ap i/index.html James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Can anyone compare/contrast features between this and Torque? That animated diagram! Torque has nothing like this. The price. Torque is Open Source, and can therefore be successfully adapted to suit the bizzare pecadilos of any organisation. From the site I can't see very much difference between this and what torque aims to provide. I'm not a torque developer, but I am a torque user, and I wouldn't want to move away from torque on the basis of what I've seen. Torque is highly flexible and can be adapted, for instance, to produce HTML forms servlets or GUI components that represent the data objects as well as the OR layer code. This represents real productivity gain, and encapsulates the concepts of best-practice,patterns and re-use in a tool which can spit out functioning bespoke data management applications in response to a DB schema, leaving the developers only to add the code which adds real commercial value to the product. IMO torque used in this way allows developers to concentrate on the 20% of the code which generates 80% of the revenue. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/26/02 2:30 PM, Steve A. Olson [EMAIL PROTECTED] wrote: Regarding Generators ... not really O/R ... but we've had success with SQLTags (www.sqltags.org) that uses a generator to produce a java class and JSP tag for each table defined by the JDBC metadata. Each tag knows how to compose an insert, update, and delete statement; provides bean-style access to each column in the table; provides bean-style access to each parent foreign and child key for the underlying table. The tags can be nested to provide master-detail relationships based on the foreign key name-- without any SQL or JOINS. SQLTags is currently very early in development, but we would welcome feedback from anyone who is interested. --Steve Olson Bah. Throws the entire concept of MVC out the window. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Jon Scott Stevens wrote: [snip] Bah. Throws the entire concept of MVC out the window. Which is a bad thing? -- Andy Armstrong, http://www.tagish.co.uk/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Subproject Proposal - crossdb
From an outsider's perspective, you probably need a new proposal. Un saludo, Alex. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: jueves 25 de abril de 2002 3:06 Para: Jakarta General List Asunto: RE: RE: Subproject Proposal - crossdb So, I'm kind of curious what the general consensus is regarding this. Seems to be in various directions. Travis Original Message From: Jeff Schnitzer [EMAIL PROTECTED] Sent: 2002-04-24 To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Subproject Proposal - crossdb From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- 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]
RE: RE: Subproject Proposal - crossdb
So, I'm kind of curious what the general consensus is regarding this. Seems to be in various directions. I think JDBC should be a lot better; it should incorporate all the features of CrossDB (though maybe a little different), and some more. Then there should be higher-level tools like Torque that use it. Since JDBC has limitations, there should be something like a patch library that adds the extra features, while staying on the same level as JDBC. Torque should then use that. Whether the library should be a part of Torque or not is really only of marketing/exposure/etc concern; as long as its decoupled I'm happy. Jon indicates that this low level library already exists within Torque and that it is easy to use. If this is true, it may perhaps need some decoupling, and some of the stuff from CrossDB and similar OSS products fed into it. Since I will probably not do the programming of any of that anytime soon(no cycles), this is very IMHO. cheers, - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Exactly. I haven't seen a decent one so far (except for NeXT/Apple WebObjects). So if you want to compare O/R with text editors (like it was done before in this thread), imagine a world with vi and notepad as the only 2 choices. Emacs and MS Word 6.0 are yet to be invented. Wow... A world without Word 6.0? Where do I sign up!!!??? Torque is nice, but you have to specify the database first in the XML. Usually, I prefer to code Java instead of XML. If it was the other way around, it would have been our primary choice. No flames please: different use cases call for different tools. Torque would have been perfect for a set of tables which you can define completely from the beginning, and make a few changes along the way. In our case, the set of tables was meant to grow and be expandable. This doesn't have to be hard either way. On my last project with WebObjects, database have grown from 15 to 100 tables along the way (in about 9 month). With a simple 1 screen GUI tool and a built in class generator we *never* had problems synchronizing (or rather evolving) the code base. Products like WebObjects or Cayenne, though they internally work off of the model file (XML), still make your code easy to change. But of course this varies from product to product. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik Home of Cayenne - O/R Persistence Framework http://objectstyle.org/cayenne/ email: andrus-jk at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Subproject Proposal - crossdb
Put [VOTE] in the subject tag and you'll get a definitive answer. (I'm not sure you'll like it) Otherwise you'll get just discussion. Might want to give http://jakarta.apache.org/site/newproject.html another gander. Furthermore, you've gotten pretty definitive feedback from some folks on here. Here is who gets a binding vote: http://jakarta.apache.org/site/whoweare.html (See under the PMC) -Andy On Wed, 2002-04-24 at 21:05, [EMAIL PROTECTED] wrote: So, I'm kind of curious what the general consensus is regarding this. Seems to be in various directions. Travis Original Message From: Jeff Schnitzer [EMAIL PROTECTED] Sent: 2002-04-24 To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Subproject Proposal - crossdb From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- 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] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Hi, As a side note. I have heard good things about http://hibernate.sourceforge.net/ which is yet another persistence layer. Unlike all the other ones this does not force you to work within a particular model of development. ie It does not force you to regenerate sources (ie Torque), postcompile (ie Entity beans), or process it through bytecode augmenter (ie JDO). The persisted objects are simple java beans with setters and getters. The setters/getters need not be public but the system will only persist javabean properties. Anyways it looks like a very kool idea but I have not yet tried it. And before I jump into it I was wondering if anyone else has had a go? The main thing I guess I am interested in is the performance as none of its docs talk about how they cache instances of javabeans or when the beans are made stale etc. -- Cheers, Peter Donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/25/02 3:37 PM, Peter Donald [EMAIL PROTECTED] wrote: Hi, As a side note. I have heard good things about http://hibernate.sourceforge.net/ which is yet another persistence layer. Unlike all the other ones this does not force you to work within a particular model of development. ie It does not force you to regenerate sources (ie Torque), postcompile (ie Entity beans), or process it through bytecode augmenter (ie JDO). The persisted objects are simple java beans with setters and getters. The setters/getters need not be public but the system will only persist javabean properties. Anyways it looks like a very kool idea but I have not yet tried it. And before I jump into it I was wondering if anyone else has had a go? The main thing I guess I am interested in is the performance as none of its docs talk about how they cache instances of javabeans or when the beans are made stale etc. I like their quote in their FAQ... And, at runtime, reflection isn't really as slow as people say. The reality is that reflection in pre-JDK 1.4 is terribly slow compared with direct method calls. They are also missing a couple important features: Yes, with two caveats. Firstly, at present Hibernate's query language does not support composite keys very well. Secondly, the support for versioned data doesn't include support for platform dependant things like sequences or auto-increment columns. FYI, Torque's re-generation of sources is really not that big of a deal. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
On Fri, 26 Apr 2002 09:20, Jon Scott Stevens wrote: on 4/25/02 3:37 PM, Peter Donald [EMAIL PROTECTED] wrote: Hi, As a side note. I have heard good things about http://hibernate.sourceforge.net/ which is yet another persistence layer. Unlike all the other ones this does not force you to work within a particular model of development. ie It does not force you to regenerate sources (ie Torque), postcompile (ie Entity beans), or process it through bytecode augmenter (ie JDO). The persisted objects are simple java beans with setters and getters. The setters/getters need not be public but the system will only persist javabean properties. Anyways it looks like a very kool idea but I have not yet tried it. And before I jump into it I was wondering if anyone else has had a go? The main thing I guess I am interested in is the performance as none of its docs talk about how they cache instances of javabeans or when the beans are made stale etc. I like their quote in their FAQ... And, at runtime, reflection isn't really as slow as people say. The reality is that reflection in pre-JDK 1.4 is terribly slow compared with direct method calls. 1.3 reflection is a little better but the earlier stuff truly sucks ;) However the speed of reflection is such a minor part in persistence layer I could not see how it would effect performance. Especially given that you are going through jdbc possibly over IP to get to the underlying DataSource. What I guess the main performance characteristeric will be how they handle the instance cache, invalidation and so forth. Unfortunately I can't see any stuff on their websote regarding that. FYI, Torque's re-generation of sources is really not that big of a deal. Depends on how often the schema changes ;) Or if you need to map it in different ways in different systems. However the main reason that I was looking at this was because the persistence layers suck in a distributed application. You end up creating dummy Value Objects for each persisted object or for each view which are 90% identical to actual persistent objects (minus the persistence framework specific parts). Sou you end up with something like following in torque MyData (The Biz Object) MyDataVO (The Value Object) MyDataPeer (The Peer) AbstractMyData (the abstract biz object) AbstractMyDataPeer (The abstract Peer) And the only one decoupled from the persistence framework is MyDataVO. In an ideal situation you would just have a single object MyData that is free from persistence framework and is nice and simple. (and basically a clone of MyDataVO). The rest of the stuff could be dynamically configured at runtime - including the mapping to physical datasource. Any system that did that and did not have all the rest of the cruft would be a sure winner IMHO. -- Cheers, Peter Donald -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
I have not dug into this, but a friend of mine raves about it: http://www.softwaretree.com/products/jdx/Jdx1.htm Can anyone compare/contrast features between this and Torque? Peter - how does this jive with your wish list? Erik - Original Message - From: Peter Donald [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Thursday, April 25, 2002 9:09 PM Subject: Re: Subproject Proposal - crossdb On Fri, 26 Apr 2002 09:20, Jon Scott Stevens wrote: on 4/25/02 3:37 PM, Peter Donald [EMAIL PROTECTED] wrote: Hi, As a side note. I have heard good things about http://hibernate.sourceforge.net/ which is yet another persistence layer. Unlike all the other ones this does not force you to work within a particular model of development. ie It does not force you to regenerate sources (ie Torque), postcompile (ie Entity beans), or process it through bytecode augmenter (ie JDO). The persisted objects are simple java beans with setters and getters. The setters/getters need not be public but the system will only persist javabean properties. Anyways it looks like a very kool idea but I have not yet tried it. And before I jump into it I was wondering if anyone else has had a go? The main thing I guess I am interested in is the performance as none of its docs talk about how they cache instances of javabeans or when the beans are made stale etc. I like their quote in their FAQ... And, at runtime, reflection isn't really as slow as people say. The reality is that reflection in pre-JDK 1.4 is terribly slow compared with direct method calls. 1.3 reflection is a little better but the earlier stuff truly sucks ;) However the speed of reflection is such a minor part in persistence layer I could not see how it would effect performance. Especially given that you are going through jdbc possibly over IP to get to the underlying DataSource. What I guess the main performance characteristeric will be how they handle the instance cache, invalidation and so forth. Unfortunately I can't see any stuff on their websote regarding that. FYI, Torque's re-generation of sources is really not that big of a deal. Depends on how often the schema changes ;) Or if you need to map it in different ways in different systems. However the main reason that I was looking at this was because the persistence layers suck in a distributed application. You end up creating dummy Value Objects for each persisted object or for each view which are 90% identical to actual persistent objects (minus the persistence framework specific parts). Sou you end up with something like following in torque MyData (The Biz Object) MyDataVO (The Value Object) MyDataPeer (The Peer) AbstractMyData (the abstract biz object) AbstractMyDataPeer (The abstract Peer) And the only one decoupled from the persistence framework is MyDataVO. In an ideal situation you would just have a single object MyData that is free from persistence framework and is nice and simple. (and basically a clone of MyDataVO). The rest of the stuff could be dynamically configured at runtime - including the mapping to physical datasource. Any system that did that and did not have all the rest of the cruft would be a sure winner IMHO. -- Cheers, Peter Donald -- 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]
Re: Subproject Proposal - crossdb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Scott Stevens [EMAIL PROTECTED] writes: If anything, crossdb is something that is a few generations behind Torque in terms of functionality and design. http://jakarta.apache.org/turbine/torque/ Yeah... I was going to point this out. Funny how all the rage recently seems to be creating these OR tools. snip/ It is a problem people can understand and is easy to become fascinated with. Similar to they way everyone in the world has created their own text editor. Kevin - -- Kevin A. Burton ( [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - [EMAIL PROTECTED], Web - http://relativity.yi.org/ The truest test of civilization, culture, and dignity is character, not clothing. -- Mahatma Gandhi -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8xlhQAwM6xb2dfE0RAh7jAKCYgo8yhODZeobfHAc1OxJL+T9UyACffSHN CuB0YbEB5SaXo0XboapTcLE= =v0A0 -END PGP SIGNATURE- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Hi Kevin, Jon Scott Stevens [EMAIL PROTECTED] writes: If anything, crossdb is something that is a few generations behind Torque in terms of functionality and design. http://jakarta.apache.org/turbine/torque/ Yeah... I was going to point this out. Funny how all the rage recently seems to be creating these OR tools. snip/ It is a problem people can understand and is easy to become fascinated with. Similar to they way everyone in the world has created their own text editor. Kevin I can imagine why people do their OR tool: because existing ones do not fulfill their necessities. In fact, that's what happened to me recently. Torque is nice, but you have to specify the database first in the XML. Usually, I prefer to code Java instead of XML. If it was the other way around, it would have been our primary choice. No flames please: different use cases call for different tools. Torque would have been perfect for a set of tables which you can define completely from the beginning, and make a few changes along the way. In our case, the set of tables was meant to grow and be expandable. Besides, database layers are not so difficult to build. Un saludo, Alex Fernández.
RE: Subproject Proposal - crossdb
Hi Amarendran,
If you analyse the database, then you have to define it first using an SQL
script, or something. We felt the need for a tool that, taking a set of
classes, created the tables for us and filled them with the objects.
For example, if we have
public class Nested
{
private int a;
}
and
public class Container
{
private String primaryKey;
private int b;
private Nested nested;
}
the database layer should create two tables, add a foreign key to Nested,
and map any instances to database tables using the primaryKey field.
Un saludo,
Alex.
-Mensaje original-
De: Amarendran Subramanian [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles 24 de abril de 2002 16:10
Para: 'Jakarta General List'
Asunto: AW: Subproject Proposal - crossdb
Torque is nice, but you have to specify the database first
in the XML.
Usually, I prefer to code Java instead of XML. If it was the
other way
i solved this by writing a little tools that analyzes the database
and generates the xml for me. but this is for my own tool not
for torque ;)
it also reads the foreign keys and creates the right
references in the
mapping xml. additional stuff is done in a seperate
manual.xml. works fine
!
--amar
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Check out jdocentral.org, vendors implementing the Java Data Object (JSR-12 jcp.org) specification do that stuff. I personally like Zodo JDO (http://www.solarmetric.com/). It is pretty slick, it does exactly what you want to do. Given a class that you build in Java it can generate tables and make the classes Persistence Capable. Thanks, Bala __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Fernandez Martinez, Alejandro wrote: I can imagine why people do their OR tool: because existing ones do not fulfill their necessities. In fact, that's what happened to me recently. Exactly. I haven't seen a decent one so far (except for NeXT/Apple WebObjects). So if you want to compare O/R with text editors (like it was done before in this thread), imagine a world with vi and notepad as the only 2 choices. Emacs and MS Word 6.0 are yet to be invented. Torque is nice, but you have to specify the database first in the XML. Usually, I prefer to code Java instead of XML. If it was the other way around, it would have been our primary choice. No flames please: different use cases call for different tools. Torque would have been perfect for a set of tables which you can define completely from the beginning, and make a few changes along the way. In our case, the set of tables was meant to grow and be expandable. This doesn't have to be hard either way. On my last project with WebObjects, database have grown from 15 to 100 tables along the way (in about 9 month). With a simple 1 screen GUI tool and a built in class generator we *never* had problems synchronizing (or rather evolving) the code base. Products like WebObjects or Cayenne, though they internally work off of the model file (XML), still make your code easy to change. But of course this varies from product to product. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik Home of Cayenne - O/R Persistence Framework http://objectstyle.org/cayenne/ email: andrus-jk at objectstyle dot org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Now I wonder if using crossdb for Torque would be a good idea. Reason being is that you wouldn't have to rebuild all your classes and scripts like you would using Torque now if you wanted to use a different database. Or even modifying the database, you wouldn't have to rebuild everything, just change it in one spot and run it. And when distributing it, the end user wouldn't need to run the builds again either, they could just package it in a war file or something, get the right crossdb implementation and run it. Food for thought. Travis -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/24/02 8:13 AM, Bala Kamallakharan [EMAIL PROTECTED] wrote: I personally like Zodo JDO (http://www.solarmetric.com/). It is pretty slick, it does exactly what you want to do. Given a class that you build in Java it can generate tables and make the classes Persistence Capable. Thanks, Bala http://www.solarmetric.com/Software/Kodo_JDO/pricing.php Only $3000 to deploy it! Bah. This stuff should be free. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] RE: Subproject Proposal - crossdb
Thanks for the plug. Whenever I need a commercial product, I will certainly use Zodo JDO. For now, I will stick to free software. Un saludo, Alex. -Mensaje original- De: Bala Kamallakharan [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 24 de abril de 2002 17:13 Para: Jakarta General List Asunto: RE: Subproject Proposal - crossdb Check out jdocentral.org, vendors implementing the Java Data Object (JSR-12 jcp.org) specification do that stuff. I personally like Zodo JDO (http://www.solarmetric.com/). It is pretty slick, it does exactly what you want to do. Given a class that you build in Java it can generate tables and make the classes Persistence Capable. Thanks, Bala __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
At 9:30 AM -0600 4/24/02, [EMAIL PROTECTED] wrote:
Now I wonder if using crossdb for Torque would be a good idea.
Reason being is that you wouldn't have to rebuild all your classes
and scripts like you would using Torque now if you wanted to use a
different database. Or even modifying the database, you wouldn't
have to rebuild everything, just change it in one spot and run it.
And when distributing it, the end user wouldn't need to run the
builds again either, they could just package it in a war file or
something, get the right crossdb implementation and run it.
is it time to move this discussion to the Torque developer list,
then? (Presumably turbine-dev).
Just a thought...
Joe
(BTW, I had figured out that Torque is decoupled from Turbine, but
what would be the harm in promoting it to a top level project?)
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
tune in posse radio: http://www.live365.com/stations/289268
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Joe Germuska [EMAIL PROTECTED] writes: At 9:30 AM -0600 4/24/02, [EMAIL PROTECTED] wrote: Now I wonder if using crossdb for Torque would be a good idea. Reason being is that you wouldn't have to rebuild all your classes and scripts like you would using Torque now if you wanted to use a different database. Or even modifying the database, you wouldn't have to rebuild everything, just change it in one spot and run it. And when distributing it, the end user wouldn't need to run the builds again either, they could just package it in a war file or something, get the right crossdb implementation and run it. is it time to move this discussion to the Torque developer list, then? (Presumably turbine-dev). Just a thought... +1 mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
http://www.solarmetric.com/Software/Kodo_JDO/pricing.php Only $3000 to deploy it! Bah. This stuff should be free. Maybe this is a project for Jakarta :-) I am interested in an Open Source Alternative, I am sure a lot of folks are JDO spec came out a couple of months back...I am sure we can develop an alternative? Thanks, Bala __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Subproject Proposal - crossdb
So, I'm kind of curious what the general consensus is regarding this. Seems to be in various directions. Travis Original Message From: Jeff Schnitzer [EMAIL PROTECTED] Sent: 2002-04-24 To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Subproject Proposal - crossdb From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Uhhh: Outer joins? Fetch data across multiple objects? Aggregation queries? Torque is an O/R mapping framework, with all of the inherent limitations of trying to make relational data look like objects. Crossdb is a database-independent abstraction of SQL (not JDBC, that's an important distinction!). These are not competitive facilities; in fact they should be highly complementary. At the moment, Torque's extremely limited Criteria object has a tough time with simple conditions like WHERE bob 5 and bob 10. Subqueries and joins are hopeless. Crossdb is what Torque desperately needs - a good database-independent way of specifying sophisticated conditions. The WhereClause in Crossdb could be substituted wholesale for Criteria. And for those of us that have to query our databases and obtain results which do not map 1-to-1 with a single object (such as anything that involves a group by or an outer join), we can bypass Torque and still have database independence. I think both Torque and Crossdb (if it has the community) are very much needed as top-level Jakarta projects. They are both bread-and-butter server development tools. Putting Crossdb under Torque makes about as much sense as putting Torque under Turbine. Oh, and Jon, the comparison with ECS is not very good. Web pages are a creative endeavor, whereas SQL statements are short and built by hard-core programmers. Also, simple HTML does not suffer from the problem of every web browser on the planet requiring a slightly different syntax for putting columns in a table... Velocity might be less useful if a separate template had to be written for every single web browser. Jeff Schnitzer [EMAIL PROTECTED] -- 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]
RE: Re: Subproject Proposal - crossdb
[EMAIL PROTECTED] wrote on 22/04/2002 03:59:43 PM: Actually Jon, Torque and crossdb are quite a bit different. Torque is pre generated and requires some preliminary setup and doesn't deal with SQL statements directly. Whereas crossdb is on the fly and is an object oriented way of creating SQL statements that are database independent. Torque row insert example after generation (taken from tutorial): Publisher addison = new Publisher(); addison.setName(Addison Wesley Professional); addison.save(); Author bloch = new Author(); bloch.setFirstName(Joshua); bloch.setLastName(Bloch); bloch.save(); crossdb row insert example: InsertQuery iq = factory.getInsertQuery(); iq.setTable(Employees); iq.addAutoIncrementColumn(emp_id); And for databases without an auto-increment feature?? iq.addColumn(emp_name, Travis Reeder); iq.addColumn(emp_department, Development); iq.execute(conn); Quite a bit different don't you think? Tim: I did read that page and thought I covered the more important points. Is there a formal way of doing these proposals? Travis [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/21/02 11:38 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: iq.addAutoIncrementColumn(emp_id); And for databases without an auto-increment feature?? FYI, Torque looks at what database driver you are using an will generate the right SQL/process to emulate auto-increment (assuming your database supports that...for example, MySQL will generate auto-increment columns...oracle will generate sequences). Torque also has a built-in IDBroker (based on Scott Ambler's design ideas) which you can use instead of auto-increment. This can actually outperform auto-increment and is 100% cross database compatible. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
I never said they were the same. I said that crossdb is a few generations behind Torque in design and thinking. In the sense that Torque is an object-relational tool and crossdb is not, Torque has a newer design. That does not mean relational tools do not have a place in Java anymore. You also left out all the code related to getting the 'conn' object. Torque abstracts all that away so it isn't necessary at all. Which is not valid in every use case. CrossDB uses a factory. Another problem with crossdb design is that you are defining all of the database logic within the code instead of abstracting it elsewhere. Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. What is the benefit of using crossdb over Torque? You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. You do not have to worry about typical O/R problems such as speed impediments. You can use crossDB in an interactive mode (like with BSH), while you cannot with Torque. I could go on and on, but I see no point. Summary: Torque is a persistence layer that uses O/R mapping to use a database to provide persistence. A persistence layer is a handy tool in many server applications. CrossDB is a database abstraction layer that uses the Factory and the Builder pattern a lot which enables you to write code that works on several databases, transparantly. You can see it as an extension to JDBC. Database abstraction layers are useful in any application that talks to databases. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. Note: I gathered all this from just three code snippets on the CrossDB site and extensive use of Torque in my projects, so I may be wrong. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
For dbs without an auto_inc feature, that db implementation would ignore this or handle it accordingly. Up to that implementation. Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-22 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb on 4/21/02 11:38 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: iq.addAutoIncrementColumn(emp_id); And for databases without an auto-increment feature?? FYI, Torque looks at what database driver you are using an will generate the right SQL/process to emulate auto-increment (assuming your database supports that...for example, MySQL will generate auto-increment columns...oracle will generate sequences). Torque also has a built-in IDBroker (based on Scott Ambler's design ideas) which you can use instead of auto-increment. This can actually outperform auto-increment and is 100% cross database compatible. -jon -- Nixon: At least with liquor, I don't lose motivation. -- 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]
RE: RE: Subproject Proposal - crossdb
Thanks Leo, I couldn't have answered this better myself. ;-) Travis Original Message From: Leo Simons [EMAIL PROTECTED] Sent: 2002-04-22 To: Jakarta General List [EMAIL PROTECTED] Subject: RE: Subproject Proposal - crossdb I never said they were the same. I said that crossdb is a few generations behind Torque in design and thinking. In the sense that Torque is an object-relational tool and crossdb is not, Torque has a newer design. That does not mean relational tools do not have a place in Java anymore. You also left out all the code related to getting the 'conn' object. Torque abstracts all that away so it isn't necessary at all. Which is not valid in every use case. CrossDB uses a factory. Another problem with crossdb design is that you are defining all of the database logic within the code instead of abstracting it elsewhere. Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. What is the benefit of using crossdb over Torque? You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. You do not have to worry about typical O/R problems such as speed impediments. You can use crossDB in an interactive mode (like with BSH), while you cannot with Torque. I could go on and on, but I see no point. Summary: Torque is a persistence layer that uses O/R mapping to use a database to provide persistence. A persistence layer is a handy tool in many server applications. CrossDB is a database abstraction layer that uses the Factory and the Builder pattern a lot which enables you to write code that works on several databases, transparantly. You can see it as an extension to JDBC. Database abstraction layers are useful in any application that talks to databases. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. Note: I gathered all this from just three code snippets on the CrossDB site and extensive use of Torque in my projects, so I may be wrong. - Leo -- 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]
RE: Subproject Proposal - crossdb
From: Leo Simons [mailto:[EMAIL PROTECTED]] Torque is a persistence layer that uses O/R mapping to use a database to provide persistence. A persistence layer is a handy tool in many server applications. CrossDB is a database abstraction layer that uses the Factory and the Builder pattern a lot which enables you to write code that works on several databases, transparantly. You can see it as an extension to JDBC. Database abstraction layers are useful in any application that talks to databases. I would add, that having a database abstraction layer doesn't prevent you from writing a persistence layer. If a project had a need to hand-craft their persistence layer (not sure why, but it's entirely possible), and a requirement to be able to connect to different database implementations at runtime (I know of products with that requirement) then it might be reasonable to write that persistence layer using CrossDB. You aren't scattering database logic throughout your code. You are centralising it into one chunk of code. You could read your column names from resources if you wished. At some point some piece of code has to use jdbc to talk to your database. If you need to talk to multiple databases (or even if you don't), then an abstraction like CrossDB may be suitable. I've never used it, I probably wouldn't use it, but if there is a need for people to still use JDBC directly (and I believe there is, in some cases), then a tool like CrossDB is not without merit. Not that this is in any way endorsing it as a jakarta project, since the requirement there are more about community and commitment than use cases. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: I never said they were the same. I said that crossdb is a few generations behind Torque in design and thinking. In the sense that Torque is an object-relational tool and crossdb is not, Torque has a newer design. That does not mean relational tools do not have a place in Java anymore. More confusion: Torque doesn't have a 'newer design'. It has a more mature design. Torque has been around for about 3-4 years now. You also left out all the code related to getting the 'conn' object. Torque abstracts all that away so it isn't necessary at all. Which is not valid in every use case. CrossDB uses a factory. Huh? Not to grab the 'conn' object. Another problem with crossdb design is that you are defining all of the database logic within the code instead of abstracting it elsewhere. Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. Right...like using JSP over Velocity is a choice. That said, JSP still sucks. :-) What is the benefit of using crossdb over Torque? You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. That is like trying to argue that using ECS is the way to write HTML. You do not have to worry about typical O/R problems such as speed impediments. You can use crossDB in an interactive mode (like with BSH), while you cannot with Torque. Huh? I don't see why you can't use Torque with BSH. I could go on and on, but I see no point. Summary: Torque is a persistence layer that uses O/R mapping to use a database to provide persistence. A persistence layer is a handy tool in many server applications. CrossDB is a database abstraction layer that uses the Factory and the Builder pattern a lot which enables you to write code that works on several databases, transparantly. You can see it as an extension to JDBC. Database abstraction layers are useful in any application that talks to databases. Torque is that as well...however, it doesn't use the same Factory/Builder pattern because it doesn't need to. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Right...like using JSP over Velocity is a choice. That said, JSP still sucks. :-) -1 - you're wrong. JSP doesn't suck.. . IT SUCKS REALLY MAJORLY BAD! ;-) I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Yeah, I'm not seeing a compelling need served here either...religion aside. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. That is like trying to argue that using ECS is the way to write HTML. Sometimes it is. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. O/R mappers are not always appropriate. For example, in torque's case, when you are dealing with an existing database that was not generated by torque and does not have a structure that is appropriate to O/R mapping. I can see that in such a case having a mechanism to code SQL in a cross database way could be useful. There is room for tools of both sorts. Different levels of database abstraction are appropriate for different use cases. Hence, Village. (No stance on whether this should be a Jakarta project is implied by this message). -- jt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Torque doesn't have a 'newer design'. It has a more mature design. Torque has been around for about 3-4 years now. SQL's been around for 20. APIs to create SQL statements have been around for about as long. Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. Right...like using JSP over Velocity is a choice. That said, JSP still sucks. :-) A strange comparison. JSP and Velocity fulfill the same use case, where JSP does it badly and Velocity rocks. That is nto the case here. What is the benefit of using crossdb over Torque? You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. That is like trying to argue that using ECS is the way to write HTML. It is not. How easy (or sensible) is it to call an ancient stored procedure written in a procedural language using Torque? While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Since you're talking examples, let me as well: I have a 25 year old banking application, for which was written 12 years ago an SQL layer to integrate it with the newer tools. To this was added, 6 years ago, another layer that used stored procedures for everything. Then, 3 years ago, a tool was written to pipe all info from that db, using the stored procedures, into pgsql to hook up to JSP and the internet. I want to have a jar file that can be used to talk to the stored procedure layer, the piping tool, the pgsql database and also the 12 year old SQL layer because I discovered lost functionality there that I need for the new eCommerce stuff. This will be used in the existing JSP application as well as in a new management console, where the management console should also be able to talk to a much newer database application running Oracle. You can probably figure out a design where Torque fits in. But it wouldn't really be the right tool for the job. I don't know whether CrossDB is, but its use case description fits rather nicely. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 10:00 AM, James Taylor [EMAIL PROTECTED] wrote: You do not have to use an O/R layer that abstracts you away from the database you are using so much that it limits your ability to use the DB's functionality in something resembling a db-natural way. That is like trying to argue that using ECS is the way to write HTML. Sometimes it is. Um. Sure. Don't forget, I started the ECS project. Velocity has far deprecated ECS. While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. O/R mappers are not always appropriate. For example, in torque's case, when you are dealing with an existing database that was not generated by torque and does not have a structure that is appropriate to O/R mapping. I can see that in such a case having a mechanism to code SQL in a cross database way could be useful. Eh? Torque can generate its conf file from existing dataabases, so making Torque fit in isn't that much of an issue. I am also hard pressed to find a database that can't be used with Torque. Scarab is a pretty complex database and it works just dandy. There is room for tools of both sorts. Different levels of database abstraction are appropriate for different use cases. Hence, Village. Village abstracts JDBC, not databases. Torque uses Village in some places in order to make the code cleaner and simpler. Don't forget, I also wrote Village. (No stance on whether this should be a Jakarta project is implied by this message). No worries. It won't become one anytime soon. Again, I still haven't seen a convincing argument for the need for crossdb. I continue to maintain that Torque does everything crossdb does and more. On top of it, it is already a Jakarta project with a large developer and user base. http://jakarta.apache.org/turbine/torque/ -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 10:40 AM, Leo Simons [EMAIL PROTECTED] wrote: Torque doesn't have a 'newer design'. It has a more mature design. Torque has been around for about 3-4 years now. SQL's been around for 20. APIs to create SQL statements have been around for about as long. Java hasn't been around for 20 years. :-) Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. Right...like using JSP over Velocity is a choice. That said, JSP still sucks. :-) A strange comparison. JSP and Velocity fulfill the same use case, where JSP does it badly and Velocity rocks. That is nto the case here. Velocity fills a much larger usecase. Just like Torque fills a much larger usecase for OR. It is not. How easy (or sensible) is it to call an ancient stored procedure written in a procedural language using Torque? Easy. You can either write it using Torque API's (essentially, hard coding string data and passing to torque to handle) or put the code into your business object (that Torque originally generated). While these may not be accurate summaries, I hope you now do see that CrossDB and Torque are not, in the majority of use cases, alternatives to one another. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Since you're talking examples, let me as well: I have a 25 year old banking application, for which was written 12 years ago an SQL layer to integrate it with the newer tools. To this was added, 6 years ago, another layer that used stored procedures for everything. Then, 3 years ago, a tool was written to pipe all info from that db, using the stored procedures, into pgsql to hook up to JSP and the internet. I want to have a jar file that can be used to talk to the stored procedure layer, the piping tool, the pgsql database and also the 12 year old SQL layer because I discovered lost functionality there that I need for the new eCommerce stuff. This will be used in the existing JSP application as well as in a new management console, where the management console should also be able to talk to a much newer database application running Oracle. You can probably figure out a design where Torque fits in. But it wouldn't really be the right tool for the job. I don't know whether CrossDB is, but its use case description fits rather nicely. I'm sorry, but Torque sounds perfect for the job. You have Torque generate the business objects which you then write methods which talk to the old code as needed. In your JSP pages, you simply refer to the Torque objects. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 11:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Speaking of which, why isn't torgue a top-level Jakarta subproject? Last I looked, it appeared to be completely independent of Turbine. Plus, as you say here, it also has a large developer and user base. Does the Torque community want to remain as part of Turbine for any particular reason? Just curious... regards, michael Torque has been separated for about a year now. We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. Get over the mental blocks and just use the code because it is good code, good design, not because of what CVS repo it lives in. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
Torque has been separated for about a year now. We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. The one reason I can think of is exposure. Which could be seen as a good one. - Leo -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. Get over the mental blocks and just use the code because it is good code, good design, not because of what CVS repo it lives in. The exposure and not the location is here the problem. Really good code is hidden in all Jakarta projects and if you don't know that it exists (and where), you have no hint to discover it. Of course if you know every jakarta projects by heart everything is easyier but I guess not everyone has that expertise. -Vladimir -- Vladimir Bossicard www.bossicard.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
On Mon, 22 Apr 2002, Jon Scott Stevens wrote: on 4/22/02 11:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Speaking of which, why isn't torgue a top-level Jakarta subproject? Last I looked, it appeared to be completely independent of Turbine. Plus, as you say here, it also has a large developer and user base. Does the Torque community want to remain as part of Turbine for any particular reason? Just curious... regards, michael Torque has been separated for about a year now. We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. Get over the mental blocks and just use the code because it is good code, good design, not because of what CVS repo it lives in. I have no mental blocks for using it. When I found it about 4 or 5 months ago, I liked it. It is good code with a good design. The only issue I have is that I didn't know about it a year ago when it was first separated from Turbine, or even before that when I actually was looking for something like it. If the torque community doesn't want to move, that's up to them. The community is in charge. Just thought I'd ask. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
I'm not sure what all the fuss is about here, but the fact of the matter is that if you were to do a survey of developers using databases (SQL), my guess is that you would find that the majority probably still use hard sql statements. A lot of people don't see the need to use a high level system like Torque or simply just don't want to. I know people SHOULD use higher level concepts and ideas, but that's not always in tune with reality. It's the same reason some people still drop back into assembly for some things (well maybe not quite, but i'm just making a point). How about people using C when there are nice languages like Java? ;-) Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-22 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb As far as I'm concerned, you guys are arguing to use a technology that takes you 10 steps back. I just don't get it. Open your eyes. -jon -- 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]
RE: Re: Subproject Proposal - crossdb
On Mon, 22 Apr 2002 [EMAIL PROTECTED] wrote: jon, are you a bitter man? ;-) This should answer your question: http://jakarta.apache.org/site/jon.html (yes, I know it was rhetorical) regards, michael Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-22 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb on 4/22/02 11:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Speaking of which, why isn't torgue a top-level Jakarta subproject? Last I looked, it appeared to be completely independent of Turbine. Plus, as you say here, it also has a large developer and user base. Does the Torque community want to remain as part of Turbine for any particular reason? Just curious... regards, michael Torque has been separated for about a year now. We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. Get over the mental blocks and just use the code because it is good code, good design, not because of what CVS repo it lives in. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 1:47 PM, Michael McCallum [EMAIL PROTECTED] wrote: jon, are you a bitter man? ;-) I think the point he (Jon) is trying to make is why write another tool when there are entirely suitable ones out there already. You would be far better off adding you insights to an existing project than starting a new one. Bingo. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 1:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm not sure what all the fuss is about here, but the fact of the matter is that if you were to do a survey of developers using databases (SQL), my guess is that you would find that the majority probably still use hard sql statements. A lot of people don't see the need to use a high level system like Torque or simply just don't want to. I know people SHOULD use higher level concepts and ideas, but that's not always in tune with reality. We are the ones who create and encourage reality. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 2:27 PM, Ellis Teer [EMAIL PROTECTED] wrote: I had considered using Torque before I was ready to give Turbine a try. Because it's subproject I had the impression that it was dependent on Turbine. This delayed me using it by a number of months. It's placement as a subproject in my case hurt its adoption. -Ellis Teer www.sitepen.com Never assume anything. All you had to do was take the extra effort to ask a simple question. Don't blame us for your being lazy or confused. Also, at the top of the Torque page, it says: Torque was developed as part of the Turbine Framework. It is now decoupled and can be used by itself. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
Well it's beyond a starting project and it works and people use it. For what it's for, it works good. Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-22 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb on 4/22/02 1:47 PM, Michael McCallum [EMAIL PROTECTED] wrote: jon, are you a bitter man? ;-) I think the point he (Jon) is trying to make is why write another tool when there are entirely suitable ones out there already. You would be far better off adding you insights to an existing project than starting a new one. Bingo. -jon -- Nixon: At least with liquor, I don't lose motivation. -- 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]
Re: Subproject Proposal - crossdb
Jon Scott Stevens [EMAIL PROTECTED] writes: on 4/22/02 12:19 AM, Leo Simons [EMAIL PROTECTED] wrote: You also left out all the code related to getting the 'conn' object. Torque abstracts all that away so it isn't necessary at all. Which is not valid in every use case. CrossDB uses a factory. Huh? Not to grab the 'conn' object. Leo, there is nothing which prevents use of application-supplied Connection objects with Torque. That said, it's annoying to _have_ to supply a Connection for every database access, so Torque hides that from the programmer in the usual case. You do not have to worry about typical O/R problems such as speed impediments. You can use crossDB in an interactive mode (like with BSH), while you cannot with Torque. Huh? I don't see why you can't use Torque with BSH. Indeed, nothing prevents such a use case. I could go on and on, but I see no point. Summary: Torque is a persistence layer that uses O/R mapping to use a database to provide persistence. A persistence layer is a handy tool in many server applications. CrossDB is a database abstraction layer that uses the Factory and the Builder pattern a lot which enables you to write code that works on several databases, transparantly. You can see it as an extension to JDBC. Database abstraction layers are useful in any application that talks to databases. I wouldn't mind seeing Torque use CrossDB under the covers instead of Village. It would be convenient to push the database abstraction down a layer. As it stands, Torque already abstracts a plethora of RDBMS implementaitons -- CrossDB would do well to use Torque as an example. I'm sorry. I don't see that. Torque can do everything crossdb can do and more. Jon is correct. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
On Mon, 22 Apr 2002, Daniel Rall wrote: CrossDB and Torque are entirely different layers. There's no reason for someone to use CrossDB instead of Torque unless they're either a) trying to avoid or circumvent O/R entirely, or b) trying to build an O/R framework. I think (a) is a reasonably valid use case. There are people who prefer to use SQL directly when talking with a database, without O/R. There are people who prefer JDO, or EJB-based persistence, or ODBMS-es. Some even want to use XML-databases ( whatever that is ). For those who prefer SQL, creating statements that will work on multiple databases ( and get around various stupid implementations of the SQL standard ) is a serious itch. I'm not sugesting we should accept crossdb - it still needs to pass other criteria like 'community' and 'scope'. I personally don't think the 'itch' is big enough for a top-level project - probably it would be much better if crossDB would be proposed as a sub-project of either torque or commons. Just MHO, Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Jon Scott Stevens [EMAIL PROTECTED] wrote on 23/04/2002 07:35:40 AM: on 4/22/02 2:27 PM, Ellis Teer [EMAIL PROTECTED] wrote: I had considered using Torque before I was ready to give Turbine a try. Because it's subproject I had the impression that it was dependent on Turbine. This delayed me using it by a number of months. It's placement as a subproject in my case hurt its adoption. -Ellis Teer www.sitepen.com Never assume anything. All you had to do was take the extra effort to ask a simple question. Don't blame us for your being lazy or confused. tongue-in-cheekLazy, as in too lazy to make Torque a top level project/tongue-in-cheek Also, at the top of the Torque page, it says: Torque was developed as part of the Turbine Framework. It is now decoupled and can be used by itself. Which you'll never know if you don't find it. On a serious note, being a top level project means that more people will find the project. -jon -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Jon Scott Stevens [EMAIL PROTECTED] wrote on 23/04/2002 09:05:56 AM: on 4/22/02 4:08 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On a serious note, being a top level project means that more people will find the project. However, it seems that the problem isn't finding the project. Torque is listed on the Jakarta homepage. It is the realization that Torque is not coupled to Turbine that is the problem. I'll buy that. I know that when I first saw the *URL*, I tnhought it was tied to Turbine. -jon -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
on 4/22/02 4:27 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'll buy that. I know that when I first saw the *URL*, I tnhought it was tied to Turbine. http://jakarta.apache.org/torque/ Feel better now? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Leo Simons [EMAIL PROTECTED] writes: Torque has been separated for about a year now. We haven't found a reason to make it a top level project yet. I really don't understand why the location of a set of code matters. The one reason I can think of is exposure. Which could be seen as a good one. I agree, that is a very good reason. Torque is (slowly) working towards a 3.0 release ATM. When that happens, it would be reasonable for it to become a top level project to increase its exposure. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
lol. nice. Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-22 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb on 4/22/02 4:27 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'll buy that. I know that when I first saw the *URL*, I tnhought it was tied to Turbine. http://jakarta.apache.org/torque/ Feel better now? -jon -- 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]
Re: Subproject Proposal - crossdb
...and it would be foolish to argue with the 'right' angles of orthogonality. ;) -Ellis Andrew C. Oliver wrote: You do have to admit it does seem a bit of a violation of orthogonality. Then again, I never really cared for helicopters anyhow ;-) -Andy On Mon, 2002-04-22 at 17:35, Jon Scott Stevens wrote: on 4/22/02 2:27 PM, Ellis Teer [EMAIL PROTECTED] wrote: I had considered using Torque before I was ready to give Turbine a try. Because it's subproject I had the impression that it was dependent on Turbine. This delayed me using it by a number of months. It's placement as a subproject in my case hurt its adoption. -Ellis Teer www.sitepen.com Never assume anything. All you had to do was take the extra effort to ask a simple question. Don't blame us for your being lazy or confused. Also, at the top of the Torque page, it says: Torque was developed as part of the Turbine Framework. It is now decoupled and can be used by itself. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
I think as a sub-project of Torque is probably a good idea taking into consideration all the conversation in regards to this. On the one hand, you have the high level OR concept which should be used, should being the important term here. But on the other hand, a person should be able to use a more direct lower level API. Both having the important similarility of being database independent. Travis Original Message From: [EMAIL PROTECTED] Sent: 2002-04-22 To: Jakarta General List [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb On Mon, 22 Apr 2002, Daniel Rall wrote: CrossDB and Torque are entirely different layers. There's no reason for someone to use CrossDB instead of Torque unless they're either a) trying to avoid or circumvent O/R entirely, or b) trying to build an O/R framework. I think (a) is a reasonably valid use case. There are people who prefer to use SQL directly when talking with a database, without O/R. There are people who prefer JDO, or EJB-based persistence, or ODBMS-es. Some even want to use XML-databases ( whatever that is ). For those who prefer SQL, creating statements that will work on multiple databases ( and get around various stupid implementations of the SQL standard ) is a serious itch. I'm not sugesting we should accept crossdb - it still needs to pass other criteria like 'community' and 'scope'. I personally don't think the 'itch' is big enough for a top-level project - probably it would be much better if crossDB would be proposed as a sub-project of either torque or commons. Just MHO, Costin -- 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]
Re: Subproject Proposal - crossdb
Jon Scott Stevens [EMAIL PROTECTED] writes: Village abstracts JDBC, not databases. Torque uses Village in some places in order to make the code cleaner and simpler. After using them both for a couple years now, I've come to the conclusion that the database abstraction layer which Torque provides would be much more appropriate at a lower layer (i.e. housed in the layer which Village provides). This is one point (basically the only point) in favor of the CrossDB project. Though competition is good, I would rather have seen the CrossDB developers enhance an existing technology (like Village) than go off and start another project. All they've done is made it all the more difficult to integrate with O/R frameworks like Torque which use existing technology organized in a different manner which accomplishes the same thing. *sigh* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Leo Simons [EMAIL PROTECTED] writes: Which has advantages over O/R, which is the reason not everyone uses O/R for everything. I'd say it is a choice instead of a problem. Right...like using JSP over Velocity is a choice. That said, JSP still sucks. :-) A strange comparison. JSP and Velocity fulfill the same use case, where JSP does it badly and Velocity rocks. That is nto the case here. Nor is it even an applicable metaphor. CrossDB and Torque are entirely different layers. There's no reason for someone to use CrossDB instead of Torque unless they're either a) trying to avoid or circumvent O/R entirely, or b) trying to build an O/R framework. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Michael McCallum [EMAIL PROTECTED] writes: jon, are you a bitter man? ;-) I think the point he (Jon) is trying to make is why write another tool when there are entirely suitable ones out there already. You would be far better off adding you insights to an existing project than starting a new one. yup -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
[EMAIL PROTECTED] writes: On Mon, 22 Apr 2002, Daniel Rall wrote: CrossDB and Torque are entirely different layers. There's no reason for someone to use CrossDB instead of Torque unless they're either a) trying to avoid or circumvent O/R entirely, or b) trying to build an O/R framework. I think (a) is a reasonably valid use case. There are people who prefer to use SQL directly when talking with a database, without O/R. There are people who prefer JDO, or EJB-based persistence, or ODBMS-es. Some even want to use XML-databases ( whatever that is ). For those who prefer SQL, creating statements that will work on multiple databases ( and get around various stupid implementations of the SQL standard ) is a serious itch. I'm not sugesting we should accept crossdb - it still needs to pass other criteria like 'community' and 'scope'. I personally don't think the 'itch' is big enough for a top-level project - probably it would be much better if crossDB would be proposed as a sub-project of either torque or commons. It would be interesting to see it as a sub-project of Torque, and have it integrated on a branch. Just thinking out loud... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
Out of morbid curiosity... I couldn't find this answered on the website... How is this different then hsql (hsqldb.sourceforge.net) and why would I want to use it as opposed to hsql? On Sun, 2002-04-21 at 21:10, [EMAIL PROTECTED] wrote: Hi, I would like to propose a new subproject for Jakarta and I will give some details below. The project is called crossdb and can be found at www.crossdb.com. What is it? crossdb is a Java API that is used to create SQL statements that are database independent. So you can write an application and have it run the exact same on any database (ie: MySQL, Oracle, MS SQL Server, etc.) The current release is ready for download and ready to use on several databases. We currently have 3 developers that work on it. I would like to have more people working on it to get more input and expertise into the different database implementations and I think the Jakarta project is the perfect place for this. I think the Jakarta project is absolutely terrific (and the Apache Foundation) as I try to use anything I can from Apache and it's projects. Basically, the value of this API is that you can save tons of time and effort changing code or learning the different SQL syntax. Now you can just use the crossdb API to write it once, run it anywhere (ie: on any database). Anyways, please let me know if you think this would be a valuable subproject for Jakarta. Thanks. Travis Reeder Chief Software Architect www.ThinkVirtual.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Subproject Proposal - crossdb
From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] On Sun, 2002-04-21 at 21:10, [EMAIL PROTECTED] wrote: The project is called crossdb and can be found at www.crossdb.com. What is it? crossdb is a Java API that is used to create SQL statements that are database independent. So you can write an application and have it run the exact same on any database (ie: MySQL, Oracle, MS SQL Server, etc.) Out of morbid curiosity... I couldn't find this answered on the website... How is this different then hsql (hsqldb.sourceforge.net) and why would I want to use it as opposed to hsql? I have nothing to do with either project, but hsql *is* a database. crossdb is a database API Your question is somewhat akin to what's the difference between jdbc and oracle? To the original poster (Travis), if you haven't already done so, you should read http://jakarta.apache.org/site/newproject.html and formulate your proposal to cover all the issues dicussed there. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subproject Proposal - crossdb
If anything, crossdb is something that is a few generations behind Torque in terms of functionality and design. http://jakarta.apache.org/turbine/torque/ Funny how all the rage recently seems to be creating these OR tools. -jon on 4/21/02 7:29 PM, Tim Vernum [EMAIL PROTECTED] wrote: From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] On Sun, 2002-04-21 at 21:10, [EMAIL PROTECTED] wrote: The project is called crossdb and can be found at www.crossdb.com. What is it? crossdb is a Java API that is used to create SQL statements that are database independent. So you can write an application and have it run the exact same on any database (ie: MySQL, Oracle, MS SQL Server, etc.) Out of morbid curiosity... I couldn't find this answered on the website... How is this different then hsql (hsqldb.sourceforge.net) and why would I want to use it as opposed to hsql? I have nothing to do with either project, but hsql *is* a database. crossdb is a database API Your question is somewhat akin to what's the difference between jdbc and oracle? To the original poster (Travis), if you haven't already done so, you should read http://jakarta.apache.org/site/newproject.html and formulate your proposal to cover all the issues dicussed there. -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Subproject Proposal - crossdb
Actually Jon, Torque and crossdb are quite a bit different. Torque is pre generated and requires some preliminary setup and doesn't deal with SQL statements directly. Whereas crossdb is on the fly and is an object oriented way of creating SQL statements that are database independent. Torque row insert example after generation (taken from tutorial): Publisher addison = new Publisher(); addison.setName(Addison Wesley Professional); addison.save(); Author bloch = new Author(); bloch.setFirstName(Joshua); bloch.setLastName(Bloch); bloch.save(); crossdb row insert example: InsertQuery iq = factory.getInsertQuery(); iq.setTable(Employees); iq.addAutoIncrementColumn(emp_id); iq.addColumn(emp_name, Travis Reeder); iq.addColumn(emp_department, Development); iq.execute(conn); Quite a bit different don't you think? Tim: I did read that page and thought I covered the more important points. Is there a formal way of doing these proposals? Travis Original Message From: Jon Scott Stevens [EMAIL PROTECTED] Sent: 2002-04-21 To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: Subproject Proposal - crossdb If anything, crossdb is something that is a few generations behind Torque in terms of functionality and design. http://jakarta.apache.org/turbine/torque/ Funny how all the rage recently seems to be creating these OR tools. -jon on 4/21/02 7:29 PM, Tim Vernum [EMAIL PROTECTED] wrote: From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] On Sun, 2002-04-21 at 21:10, [EMAIL PROTECTED] wrote: The project is called crossdb and can be found at www.crossdb.com. What is it? crossdb is a Java API that is used to create SQL statements that are database independent. So you can write an application and have it run the exact same on any database (ie: MySQL, Oracle, MS SQL Server, etc.) Out of morbid curiosity... I couldn't find this answered on the website... How is this different then hsql (hsqldb.sourceforge.net) and why would I want to use it as opposed to hsql? I have nothing to do with either project, but hsql *is* a database. crossdb is a database API Your question is somewhat akin to what's the difference between jdbc and oracle? To the original poster (Travis), if you haven't already done so, you should read http://jakarta.apache.org/site/newproject.html and formulate your proposal to cover all the issues dicussed there. -- Nixon: At least with liquor, I don't lose motivation. -- 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]
