No - this will not get you girls - so indeed - why waste time on this?

Of the 3 libraries you mentioned persist is the most similar.

Like Spring JDBC they do the "bean model" for complex objects (call
the default constructor and then the setters) where as I call the
constructor that matches the columns of the resulting relation - which
I think is more direct and flexible approach.

And then comes the question of configuration and datasource
management.

Some libraries just don't do that (persist) and some has an elaborate
approach (Spring JDBC).

What I did is this - if you write:

openConnection()

That method (which is a static import) will look at the qualified name
of the calling class and use that to look up a configuration /
datasource.

How it does the looking up depends a global setting called
configuration strategy. Out of the box - there are two strategies: One
called jndi and another called system.

If you are using the JNDI strategy (default) and your class is
gov.recovery.PerformanceMonitor - you will use the first that exists
of the following datasources:

java:/comp/env/jdbc/gov/recovery/PerformanceMonitor
java:/comp/env/jdbc/gov/recovery
java:/comp/env/jdbc/gov
java:/comp/env/jdbc/default

Now if you change the strategy to "system" - Chalk Mine instead will
use its internal connection pool / datasource manager that you
configure by system properties and like above it will for the first
definition of:

gov.recovery.PerformanceMonitor.db
gov.recovery.db
gov.db
default.db

(See docs for exact syntax.)

The point is: You can change how you get your database configurations
with changing your database code.

This solves a very common problem: You can use the simplier system
properties configuration when your code is used in a test case or a
stand-alone program and the JNDI configuration when it is deployed as
a web application or similar.

Lastly there is the library size.

Chalk Mine is 18 KB compiled. With no other dependencies than Java 5.
And it contains SQL shorthand notation, basic data mapping, the above
configuration mechanism and a connection pool.

Sure - the library has some none trivial applications of reflection,
generics etc. but the modest size sets a limit on complexity and thus
how much can wrong.

When I compare this to Hibernate or Spring / Spring JDBC - I feel like
I am introducing something of enormous complexity into my project that
I am only using very little of.

Anyway: That was my motivation for creating the library.

On Feb 26, 10:08 pm, Rakesh <[email protected]> wrote:
>  What EoD SQL is not:
>
>     * EoD SQL will not parse or validate your SQL in any way
>     * EoD SQL is not a database or database connector, it sits on top of JDBC
>     * EoD SQL will not get you girls
>
> right, thats of the short list!
>
> R :))
>
>
>
> On Thu, Feb 26, 2009 at 7:00 PM, N4Spd <[email protected]> wrote:
>
> > Existing alternatives:
>
> > - persist athttp://code.google.com/p/persist/
> > - EoD SQL athttps://eodsql.dev.java.net/
> > - Ebean athttp://www.avaje.org/
>
> > On Feb 22, 6:21 am, Christian Hvid <[email protected]> wrote:
> >> Hi Java people.
>
> >> I have been toying with simplier ways of doing embedded SQL in Java.
>
> >> And would like your comments on this one?
>
> >>http://code.google.com/p/chalkmine/
>
> >> It allows you to write code like this:
>
> >> openConnection();
> >> try {
> >>     int count = queryScalar(Integer.class, "select count(*) from
> >> people");
> >>     System.out.println("There are "+count+" people in the bin.");} finally 
> >> {
>
> >>     closeConnection();
>
> >> }
>
> >> or
>
> >> openConnection();
> >> try {
> >>     List<Person> people = queryList(Person.class, "select name,
> >> time_in_the_bin from people");
> >>     for (Person p : people)
> >>         System.out.println(p.getName()+" has been "+p.getTimeInTheBin()
> >> +" hours in the bin.");} finally {
>
> >>     closeConnection();
>
> >> }
>
> >> (Provided that Person has a constructor matching the types of name,
> >> time_in_the_bin. Probably Person(String, int).)
>
> >> Where the methods openConnection, queryScalar, queryList,
> >> closeConnection are statically imported.
>
> >> openConnection() figures out the name of the calling class, looks up a
> >> configuration, opens a connection and puts in a ThreadLocal container.
>
> >> queryScalar(Class, String, ...) performs a query with a single row
> >> result that is "cast" to the given class.
>
> >> queryList(Class, String, ...) performs a query and returns the result
> >> as a list of the given class.
>
> >> I would like to turn it into a full-fledged open source project.
>
> >> But since it is incredibly hard for a new open source project to gain
> >> traction I would like to figure out whether it is interesting enough
> >> first.
>
> >> -- Christian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to