Very nice. I really look forward details on initial migration features in trunk version. How it can be used/tested? Please give some brief details. I have compiled version from trunk so I can test.
Also its a bit off-topic, how @ManyToMany scenario is supposed to beeing used? U have User and Role tables and need ManyToMany relationship between them. How to setup it?
The new migration code will work the same way as the old generating code. So, you would call the EntityManager#migrate(Class̷ method. This would handle all of the migration tasks (including diffing the existing schema, and CREATE/ALTER/DROP to match the new one). There’s an Ant task which doesn’t work (at least, I don’t think it does), and command line invocation is also supported.
Good question with the relationship annotations. I’ll dash off a quick article today explaining how they work, as well as the @Ignore annotation, which I just realized I forgot to mention in today’s post.
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 go 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:15
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:2
at net.java.ao.schema.Generator.migrate(Generator.java:150)
at net.java.ao.EntityManager.migrate(EntityManager.java:143)
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
Subscribe to RSS Feed
July 31st, 2007 at 1:10 am
Very nice. I really look forward details on initial migration features in trunk version. How it can be used/tested? Please give some brief details. I have compiled version from trunk so I can test.
Also its a bit off-topic, how @ManyToMany scenario is supposed to beeing used? U have User and Role tables and need ManyToMany relationship between them. How to setup it?
Thanks,
David
July 31st, 2007 at 1:33 am
The new migration code will work the same way as the old generating code. So, you would call the EntityManager#migrate(Class̷
method. This would handle all of the migration tasks (including diffing the existing schema, and CREATE/ALTER/DROP to match the new one). There’s an Ant task which doesn’t work (at least, I don’t think it does), and command line invocation is also supported.
Good question with the relationship annotations. I’ll dash off a quick article today explaining how they work, as well as the @Ignore annotation, which I just realized I forgot to mention in today’s post.
July 31st, 2007 at 1:34 am
Argg, WordPress ate my comment. Suffice it to say, it’s the “migrate” method within EntityManager.
July 31st, 2007 at 2:32 am
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 go
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:15
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:2
at net.java.ao.schema.Generator.migrate(Generator.java:150)
at net.java.ao.EntityManager.migrate(EntityManager.java:143)
July 31st, 2007 at 7:43 pm
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