As any other Content Management System, Shaman manipulates two kind of
Here is a comparison between different solutions for storing both content and its metadata :
It appears clearly that an hybrid solution (RDBMS + filesystem + synchronization) is the best compromise in long-term. Synchronization is not so difficult to write, if concurrent accesses to repository are correctly managed.Intermediate solution : Prevayler
At this early development stage, we want to get a quick validation of a Model describing the Repository Data (its correct semantic would make of Shaman a development platform of choice).
Everybody knows that "dismounting" objects before putting them in a database is painful and time-consuming ("remounting" is not better). On the other hand, Open Source Object Persistence solution we looked at were relying on tricky mappings / stub generation, while putting severe restrictions to object semantics. So, things were looking bad.
...Until we found the Prevayler project. Prevayler is a clever persistence engine, which does nothing else than letting all Java objects living in memory, knowing how to restore them when needed.
Prevayler allows to program plain old Java objects, just make your
A quick-and-dirty evaluation of first Shaman production use
(2 years) gave us the following results :
This gives a total of 286.420 Buisness Objects. Taking an average of 4 implementation objects per Buisness Object, we stay around 1,2 million Java objects in memory. Tests with Prevayler show that a 32 bits JVM can handle this, with careful Garbage Collection strategy.Migration from Prevayler to JDBC
Did we add the necessary indirection level for a transparent switch from Prevayler data storage to JDBC data storage ?
No. We did'nt.
In fact this indirection level is a burden at early stages of development, when Operation interfaces may change often. The indirection level would lead to create one interface / base class for each Operation, doubling the amount of work for any update.
Once Operation interfaces will be stable, it will be possible to
split Operations parameters and implementation(s),
without breaking client code and tests.
Our latest investigations lead us to consider OJB, which seems the very best free, Open Source objet-relational mapping tool available at this time. We intend to keep Object-Oriented semantics for code clarity and maintenability, and avoid hacking into tables using JDBC directly.Conclusion
So we believe we can use Prevayler for the first year of production use. This will gave us the time to evolve towards a JDBC-based implementation once the Repository Data requirements will be well-understood.