Hi, > moving away not only from RDBMS systems as core storage
I agree. RDBMS are not the best way to store hierarchical data. > but also away from their query languages such as SQL. SQL is a very old and strange language. It does not fit very well with languages such as Java. Replacing it would be great. For some technologies, it seems that disruptive changes failed, but 'step-by-step replacement' is successful: - Replacing RDBMS with disruptive changes have failed in my view: object databases, XML databases. But O/R mapping is successful. - Chip industry: replacing x86 technology with disruptive changes has failed, the 'compatibility approach' was more successful. - Cars: the all-electric car has failed. The hydrogen car has failed. But hybrid cars are successful. - OS/2 failed, but Windows was successful (because of better MS-DOS compatibility?) (There is probably a book about that, similar to 'The Innovator's Dilemma', but I don't know it). > Jackrabbit be refactored so that each session would map to a separate > database connection. I don't think it can be done in the short term. But we should investigate it for Next Generation Persistence (http://jackrabbit.apache.org/dev/ngp.html). We need specific use cases where using multiple connections clearly helps: A test-first approach (or test-driven-development, or TDD). > don't like having the database being a driving factor in Jackrabbit design. > The way I see it we should be moving further away from relational databases, > towards a native hierarchical storage model. I agree, but some customers are more comfortable when using RDBMS as the storage. It maybe a perceived advantage only. In my view the 'compatibility approach' is great: provide RDBMS persistence managers, but work on better persistence managers (that are optimized for JCR storage). The same for Global Data Store: FileDataStore is the most logical solution. Large objects are not a good fit for databases. Anyway some still want to store them in a database. So we support a DatabaseDataStore as well. Thomas
