RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread dion
[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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons
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

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

RE: RE: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

RE: Subproject Proposal - crossdb

2002-04-22 Thread Tim Vernum
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Andrew C. Oliver
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread James Taylor
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.

RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

RE: Subproject Proposal - crossdb

2002-04-22 Thread Leo Simons
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,

Re: Subproject Proposal - crossdb

2002-04-22 Thread Vladimir Bossicard
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Michael A. Smith
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

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread Michael A. Smith
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:

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread costinm
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread dion
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread dion
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.

Re: Subproject Proposal - crossdb

2002-04-22 Thread Jon Scott Stevens
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,

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
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

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Ellis Teer
...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,

RE: Re: Subproject Proposal - crossdb

2002-04-22 Thread travis
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
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

Re: Subproject Proposal - crossdb

2002-04-22 Thread Daniel Rall
[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.