RE: Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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, 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:   
>>For additional commands, e-mail: 
>>



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[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 saw the *URL*, I tnhought it was
> tied to Turbine.

http://jakarta.apache.org/torque/

Feel better now?

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[dion]

Jon Scott Stevens <[EMAIL PROTECTED]> wrote on 23/04/2002 09:32:50 AM:

> 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?

Like I've just had my caffeine hit

> -jon

--
dIon Gillard, Multitask Consulting
Work:  http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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. 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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.
>
> 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Andrew C. Oliver]

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:   
> For additional commands, e-mail: 
> 
-- 
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:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[Andrew C. Oliver]

It takes awhile to learn an appreciation for Jon.  He's like a peculiar
wine that at first you think isn't fit for lacquer and later you start
to find yourself nodding you head a little bit, and then suddenly find
even when you roll your eyes at him you're still chuckling a bit.  But
Jon is definitely an acquired taste.  He's one of the people here that I
hope to meet if Cisco ever sends me out to San Jose.

-Andy

On Mon, 2002-04-22 at 16:27, Michael A. Smith wrote:
> 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:   
> For additional commands, e-mail: 
> 
-- 
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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Jon Scott Stevens]

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.

-jon

-- 
Nixon: "At least with liquor, I don't lose motivation."



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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.
Lazy, as in too lazy to make Torque a top level 
project

> 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 new one.

yup

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Ellis Teer]

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

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.
> 
> -jon
> 



_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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
> 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 project than
> starting a new one.

Bingo.

-jon

-- 
Nixon: "At least with liquor, I don't lose motivation."



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Re: Subproject Proposal - crossdb

[Michael McCallum]

> 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.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[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: 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:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[travis]

jon, are you a bitter man?  ;-)

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

-- 
Nixon: "At least with liquor, I don't lose motivation."


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

RE: Subproject Proposal - crossdb

[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, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Michael A. Smith]

On Mon, 22 Apr 2002, Jon Scott Stevens wrote:
> 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/

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


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

RE: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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.

> > 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 either...religion aside.




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Andrew C. Oliver]

right, but lookie here: 
http://cvs.apache.org/viewcvs/xml-cocoon2/src/webapp/WEB-INF/db/cocoondb.script?rev=1.2&content-type=text/vnd.viewcvs-markup

HSQL creates scripts based on your JDBC calls that can easily be run on 
a big boy database (like postgreSQL ...haha) -- As far as I can tell 
thats how HSQL stores the data.  And they aren't necesarilly the same 
insert/create statements that were passed in via jdbc *shrug*...they 
seem to be genericised.  (excuse my ignorance, I'm going only on the 
online docs)

So if all this thing does is thatthen I don't get it.

-Andy

Tim Vernum 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.
>
>
>
>
>
>
>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:   
>For additional commands, e-mail: 
>
>
z



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Subproject Proposal - crossdb

[Andrew C. Oliver]

yes...indeed.

>
>
>Funny how all the rage recently seems to be creating these OR tools.
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 

RE: RE: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Re: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Subproject Proposal - crossdb

[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 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:   
For additional commands, e-mail: