Jim Seach wrote:
Well, It looked pretty good to me on first read too, but I wasn't sure
how we would approach it. On re-reading it, the light bulb came on,
and I wrote my proposal.
Looks like you skimmed it, liked it, and started coming up with
implementation options! Nothing wrong with that.
(Connection, Statement, ResultSet, etc.) to execute
object-based
queries?
-Original Message-
From: Jim Seach [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 11:14 PM
To: Jakarta Commons Developers List
Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
: Sunday, April 03, 2005 1:59 PM
To: Jakarta Commons Developers List; Henri Yandell
Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
What I was envisioning is that the user would write his object persistence
using the JDBC API, the whole ball of wax, but use the Commons Persistence
JDBC Driver
of my code. I'd have
to say
that I'd be a +1 overall.
-Original Message-
From: Jim Seach [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 03, 2005 1:59 PM
To: Jakarta Commons Developers List; Henri Yandell
Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
What I
Commons Developers List
Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
James,
I understand your point, but I think my idea fits within both the letter and
spirit of Geir's proposal:
... we think that commons persisting should just enhance the mystery
and intrigue of adding
Commons Developers List
Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
James,
I understand your point, but I think my idea fits within both the
letter and
spirit of Geir's proposal:
... we think that commons persisting should just enhance the
mystery
and intrigue
members? That's what sold me! ;-)
James
-Original Message-
From: Jim Seach [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 03, 2005 8:21 PM
To: Jakarta Commons Developers List
Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
James,
You are, of course, correct and make a lot
off various and sundry expert
group
members? That's what sold me! ;-)
James
-Original Message-
From: Jim Seach [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 03, 2005 8:21 PM
To: Jakarta Commons Developers List
Subject: RE: [PROPOSAL] Commons Runtime API for Persistence
Great idea!
See if some of it can be based on Apache's iBatis SQL and DAO api.
If an API let me use iBatis SQL maps or Hibrenate, that would be great.
Also... with CoR... in esence you can just use:
execute(Map m)
for any DAO, Lucene, etc.
Just put in args in Map, when done put RESULT arraylist in
I for one like the idea, except for one thing... I've always been a bit
turned off by the persistence solutions that have their own query
language, such as Hibernate. For me, any solution that didn't work with
regular standard SQL wouldn't be optimal. I believe that if the table
names in a
Well, we could take it a step further:
We don't need to invent our own api, just adopt one and write the
necessary adapters. I propose using the JDBC api with our own
DriverManager and DataSources. The application or library developer
will handle their persistence needs using the standard JDBC
List
Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
Well, we could take it a step further:
We don't need to invent our own api, just adopt one and write the necessary
adapters. I propose using the JDBC api with our own DriverManager and
DataSources. The application or library
object-based
queries?
-Original Message-
From: Jim Seach [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 11:14 PM
To: Jakarta Commons Developers List
Subject: Re: [PROPOSAL] Commons Runtime API for Persistence
Well, we could take it a step further:
We don't need
On Apr 1, 2005 8:14 PM, Jim Seach [EMAIL PROTECTED] wrote:
Well, we could take it a step further:
We don't need to invent our own api, just adopt one and write the
necessary adapters. I propose using the JDBC api with our own
DriverManager and DataSources. The application or library
Martin Cooper wrote:
On Apr 1, 2005 8:14 PM, Jim Seach [EMAIL PROTECTED] wrote:
Well, we could take it a step further:
We don't need to invent our own api, just adopt one and write the
necessary adapters. I propose using the JDBC api with our own
DriverManager and DataSources. The application
15 matches
Mail list logo
