Comments on: An Easier Java ORM Part 4

By: foo

foo — Sat, 25 Apr 2009 02:25:32 +0000

Have you seen this one: http://www.mollypages.org/dbo ?

By: Christian

Christian — Thu, 28 Feb 2008 07:29:13 +0000

Thanks for your fast Reply Daniel.

If every do things in same way is not a proof that it is a good solution also Hmmm seems … if I realy want to get rid of the em I have to write some kind of wrapper classes. Maybe I will do this in future. Since I will need the lib for beanshell scripts maybe its a bit easier to handle the objects.

Christian

PS I realy like ActiveObjects – its my favior ORM. I have tested for a few days Apache Cayenne, Oracle TopLink, Hibernate and ActiveObjects.

By: Daniel Spiewak

Daniel Spiewak — Wed, 27 Feb 2008 18:04:14 +0000

There’s no way that you’re going to be able to get rid of EntityManager entirely (this restriction is fairly standard for ORMs). This is because to even create the instances of the interface, EntityManager must be invoked. You don’t actually extend Entity with a class, but rather with an interface (which cannot be instantiated).

By: Christian

Christian — Wed, 27 Feb 2008 15:42:06 +0000

Hello!

I have just started using Java and ActiveObjects for a library project. The goal is to use perisistant objects not in case of an application but get easy access via a lib. What I would like to develop is kind of typical access without a client need of EntityManager.

Person me = new Person();
me.setName(“Christian”);
me.save();

Person i = new Person(“name=?”, “Christian”);
System.out.println(i.getName);

Since I am a Java newbee too, how can I extend the interface with constructors?

Thank You Christian

By: daniel

daniel — Sat, 18 Aug 2007 00:12:05 +0000

Hmm, ActiveObjects out of the box sort of hides all that from you, so you can’t get to it directly. The idea is if you want to do anything advanced with either the pooling or the JDBC drivers, you’ll need to extend either the existing pool provider, or create a new pool provider yourself. This will allow you to completely control all aspects of the database pooling and even implement a library yourself. The downside to this is you must then manually pass this database provider to EntityManager thusly:

DatabaseProvider provider = new MyPoolProvider(new MySQLDatabaseProvider(uri, username, password));
EntityManager manager = new EntityManager(provider);

The “manager” instance will then use the MyPoolProvider functionality to encapsulate its database access. In fact, this is actually how the new EntityManager(String, String, String) auto-magical constructor works under the surface, just with the addition of two enums which allow auto-detection of database driver and available pool providers.

Oh, a pool provider is actually just a DatabaseProvider which delegates all of its functionality to a specified DatabaseProvider instance with the exception of the getConnection() method, which is handled in a pool-specific way. There is a PoolProvider abstract super-class which makes the implementation of new pool providers fairly trivial.

By: Kevin Hoang Le

Kevin Hoang Le — Sat, 18 Aug 2007 00:05:58 +0000

Thanks, but in your built-in integration, how do pick up the configuration, such as the max number of connections, an SQL statement to ping the DB if supported by the CP, other properties, etc. Or is there an overloaded version of EntityManager() where you could pass in the additional above-mentioned properties? Thanks

By: daniel

daniel — Fri, 17 Aug 2007 23:48:59 +0000

It requires an external pooling *library*, but integration with these libraries is built in. All you have to do is put the pooling library on your classpath, and ActiveObjects will use it. For example, I use commons-pool/commons-dbcp by placing the JARs on the classpath and then calling new EntityManager(uri, username, password) just as before. I could also use C3P0 or Proxool if I wanted to. Alternatively, I could leave the pool libraries completely off the classpath, and ActiveObjects would use the JDBC driver directly, without pooling.

By: Kevin Hoang Le

Kevin Hoang Le — Fri, 17 Aug 2007 23:32:07 +0000

Daniel,

I apologize because I have not read all 4 parts before asking questions. Does AO require an external connection pooling implementation or do you have CP built-in inside AO? Thanks

By: Daniel Spiewak

Daniel Spiewak — Wed, 01 Aug 2007 01:43:03 +0000

Yeah, I would expect that. Right now in trunk/ the migrations feature isn’t fully wired up. I haven’t actually written the “glue code” to connect the migrate() method to the schema reading and diffing features. In other words, it’s trying to create the schema all over again each time you call the method. :-S

By: David Marko

David Marko — Tue, 31 Jul 2007 08:32:39 +0000

Just used ActiveObjects from trunk and tried migration feature. On firt run AO created a new table correctly. Then I changed a JAVA class(add some additional property) and called migrate once again. This is what a got:(subdomain is a JAVA bean a store in database)

org.postgresql.util.PSQLException: ERROR: relation “subdomain” already exists
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:337)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:283)
at org.apache.commons.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228)
at net.java.ao.schema.Generator.migrate(Generator.java:150)
at net.java.ao.EntityManager.migrate(EntityManager.java:143)