Quoting Rickard Öberg Rickard Öberg <[email protected]>: > On 2010-07-31 21.01, Paul Merlin wrote: > >> * Consider not doing table management in the EntityStore. I'm > >> using LiquiBase in Streamflow for all table management, on an > >> application level, and it simplifies evolution a lot (which you > >> can't handle in the current setup). Let the EntityStore focus on > >> one thing only. > > > > I'm not sure it's valuable here as the ES is really an infrastructure > > thing and the current implementation goal is to provide a > > _non-cutomizable_ db schema. Maybe we could provide external SQL code > > per db vendor to create the schema. > > > > WDYT ? > > Well, the thing is that even if you "get it right", some time down the > line you may want to add some extra column. When that time comes it's > easier if the table management is outside of the ES. And for me, who > already uses Liquibase, I prefer to have all my database handling in one > place, as it will coincide with my application versioning. > > I could move the Liquibase wrapper from Streamflow into Qi4j, so that > you guys can use it as well.
Ok. Then we'll go this way as soon as the wrapper is available. >From what I understand, this will be only for the EntityStore, not the >Indexing as it create tables dynamically according to the application Entities. > >> * Does the entity table include a version column? In order to do > >> proper concurrency checking you pretty much have to, and then use > >> it on UPDATE calls. > > > > Much like the OptimisticLock VERSION column used by Hibernate. Good > > idea. Will do. > > Exactly. If data can be read in multiple db transactions into a > UnitOfWork for some time, then having a version column is necessary on > write, to ensure consistency. Done and pushed. Paul _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
