Re: SimpleORM vs. Cloudscape 10 / Derby

Hello Boris,

I definitiely want to support Cloudscape/Derby, and want it to replace 
HSQL as the default DB.  I like the fact that it is 100% java yet 
apparantly performs reasonably well.  (There are other good (maybe 
better?) alternatives, but Derby has the Apache logo.)

I think that we'd all be interested in a comparison between Derby and 
Oracle.  I understand that the Derby locking model is simple, no read 
behind.  But what else.  And what about performance for basic OLTP 
applications?  Please let us know.

To start with, I suggest that you simply use the default SDriver.  It is 
very SQL89 compatible and should work on any vaguely relational 
database.  Or perhaps the HSQL, which does not even assume locking. 
Neither use FOR UPDATE etc.

You can start the new driver yourself if you like.  I'd say just copy 
SDriverHSQL into SDriverDerby, delete crap and change the obvious. 
There is a list of drivers in SDriver.java which you could also update. 
  It is actually very easy because SimpleOrm is ... simple.

Regards,

Anthony

couchworx wrote:

> 

Re: Re: Sequences

Hello Dan,

To do it really properly we would need a new class SSequenceGenerator. 
It would have the crued update max.  It would then be specialized. 
SDrivers would have a default approach for that database.  And that 
could be overriden by individual table definitions using a property.

If you want to have a go the great.  I won't have time to look at 
SimpleORM for a while, so feel free to hack around!

Thanks,

Anthony

Dan Hristodorescu wrote:

> 
> 
> Hello Anthony,
> 
> I noticed that the attachments were removed from the message on the 
> Yahoo list. I've reattached them just in case and I've added the javadoc 
> comment on how to use it (call attach on every EJB call).
> 
> The driver is called like that because I needed to subclass the MSSQL 
> driver and our JDBC driver is called I-Net Opta. I remember when I 
> started using SimpleORM it was looking up the driver by name and Opta 
> wasn't a registered driver name.
> 

Re: minor fixes to new simpleorm 2.17 and question about joining

Hello Pierre,

OK, these will be addressed next release.  But are you sure that in 
MySQL one says
   Select `my funny column`, ...
instead of
   Select "my funny column", ...
Please make the change on your version and confirm.

 > select user.* from user join usergroup using( userid ) join group
 > using( groupid) where groupid=? and user.firstname=? and
 > user.lastname=?.

This query does not make sense.  I assume that you meant

 > select user.* from user join usergroup using( userid )
 > where groupid=?

I'd suggest that you just do it in two steps, essentially

select userID from usergroup where groupid=?

and then retrieve each user object in a separate step.

(SimpleORM does provide good support for both subselects and joins if 
needed, see SQuery.java.  But to start with keep it simple and optimize 
later.)

Anthony

Re: SimpleORM vs. Cloudscape 10 / Derby

Hello Anthony,

I agree that there are other alternativies, and i am sure i don't 
know all 100% java databases out there. But have a look at the RDBMS 
capabilities on http://www-
106.ibm.com/developerworks/db2/library/techarticle/dm-
0408anderson/index.html
just to name a few:
- java stored procedures and triggers
- cost based optimizer
- crash recovery
All these are high level features i know and like in Oracle RDBMS, 
and now i get all this in a 4MB footprint java database with nearly 
zero installation and administration overhead!? I hope not to wake 
up from this developer dreams ... 
My first concern was performance, so i've created a simple 4 tables 
schema (person, persontype, adress, adresstype) with proper foreign 
keys and indexes. 2 views (one on person/persontype, one on 
adress/adresstype). Then i added 10000 persons and 15000 adresses 
from our corporate oracle 9i  database. Querying the data as a 
joined selection on the 2 views (with name like '%a%') satisfied my 
needs for a responsive (single user) database. I will check out the 
client/server mode performance with concurrent users within a few 
weeks. 

for SimpleORM 
i've choosen to add a Derby Driver, and yes, it was extremely 
simple. Thanks Anthony! 

Re: Re: SimpleORM vs. Cloudscape 10 / Derby

Hello Boris,

So... How long did your benchmarks take?  What computer?  If you have 
time I would love to know how oracle performs on the same tests.  (You'd 
have to install it on the test DB.

I've copied your derby driver into the codebase, it will be part of the 
next release.

Thanks,

Anthony

couchworx wrote:

> 
> Hello Anthony,
> 
> I agree that there are other alternativies, and i am sure i don't 
> know all 100% java databases out there. But have a look at the RDBMS 
> capabilities on http://www-
> 106.ibm.com/developerworks/db2/library/techarticle/dm-
> 0408anderson/index.html
> just to name a few:
> - java stored procedures and triggers
> - cost based optimizer
> - crash recovery
> All these are high level features i know and like in Oracle RDBMS, 
> and now i get all this in a 4MB footprint java database with nearly 

EJB

I am currently leveraging SimpleORM in an EJB component.
I can perform the calls and all.

In the bean I use:

/**
     * Gets current connection to the connection pool.
     */

    private void attachConnection(String name) throws Exception {
        InitialContext initCtx = new InitialContext();
        DataSource ds = (javax.sql.DataSource)
initCtx.lookup("java:/DefaultDS"); // TODO: put this in a parm in the xml
descriptor
        Connection con = ds.getConnection();
        SConnection.attach(con, name);
        SConnection.begin(); // do not start a new transac
    }

and in a business method I do:

    try {
                attachConnection("InfoSystemCon");
                String paramValue = <params>.getParameter("accountId");
                acct = (Account) Account.meta.findOrCreate(paramValue);
                if (acct.isNewRow() == false) { // found !
                    acct.detach();
                    found = true;
                }

Re: EJB

Hi,

this is what I did (once upon a time):

	
	try {
         /* SimpleORM specific code
         InitialContext ctx = new InitialContext();
         DataSource ds = (javax.sql.DataSource) 
ctx.lookup("java:PostgresDS");
         con = ds.getConnection();
         SConnection.attach(con, "getAllEcr");
         SConnection.begin();
	.......
         SConnection.flush();
         SConnection.detachWithoutClosing();
         //con.close(); prevents jboss from sending exception (done
	in finally)

	} catch (Exception e) {
	....
         } finally {
             try {
                 if (con != null) {
                     con.close();
                 }
             } catch (Exception e) {
                 // Container will take care of that
             }
         }

Re: EJB

Hi Franck,

Thanks!

I do not understand why having the close in the finally instead of inside
the try block would do any difference for JBoss (I understand why it has to
be in the finally anyhow).

My current issue is rather linked to the fact that my EJB is configured as
Container in the ejb-jar.xml.

I would rather use Spring and let go of the EJBs but before doing that, I've
to make it work in the EJB container... The goal being to prove that EJB
have a lot of issues that can be avoided by using something lighter. So, I
am basically building a case.

Best regards,
/Phil

----- Original Message -----
From: "Franck Routier" <franck.routier <at> axege.com>
To: <SimpleORM <at> yahoogroups.com>
Sent: Monday, 07 February, 2005 09:00
Subject: Re: [SimpleORM] EJB

> Hi,
>
> this is what I did (once upon a time):
>

RE: EJB

Inconsistency in quoting SQL identifiers

Hi all,

I am experiencing problems when running SimpleORM 2.17 against a
Postgres DB (7.1 or 8.0.0).
All of the examples fail with Postgres.

The problem is the case sensitivity of SQL identifiers: AFAIK the SQL
spec says that unquoted names should be forced to all upper case (so
XX_DEPARTMENT is equivalent to "XX_DEPARTMENT"). Postgres forces them to
lower case (so XX_DEPARTMENT is equivalent to "xx_department") which is
not quite the same but has the same effect that unquoted names are not
case sensitive. I did not find a way to change that behaviour of
Postgres.

So, when I run IdentFKeysTest.java, I get the following:

CREATE TABLE "XX_DEPARTMENT"(
	...
)
CREATE TABLE "XX_EMPLOYEE"(
	...
    CONSTRAINT "XX_EMPLOYEE_5_XX_DEPARTMENT"
      FOREIGN KEY ("DEPT_ID")
      REFERENCES XX_DEPARTMENT (DEPT_ID),
	...
)
    : java.sql.SQLException: ERROR: relation "xx_department" does not
exist
java.sql.SQLException: ERROR: relation "xx_department" does not exist

Since the inconsitency in Quoting, Postgres reads 'REFERENCES
XX_DEPARTMENT' as 'REFERENCES xx_department' but the table name is in
fact all upper case.

I fixed this by adding a 'quoteTable()' in SDriver.foreignKeysSQL() and
quote a 'quoteColumn()' in SDriver.aReferenceSQL() but I'm not sure if
this won't have a drawback on other DBS than Postgres.
Additonally, the examples have to be changed where raw queries are
involved.

/Martin

--
Your font is:      Proportional  Monospaced
                                      ^
The amazing Font-o-Meter!

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> To unsubscribe from this group, send an email to:
    SimpleORM-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/