I'm really glad this topic was opened here. The major challenge here is that eZ Publish was RDBMS designed from the beggining. It's not a blocker, but one of the biggest challenge is to make it "non-SQL DB aware". What follows is an aggregate of our (eZ Engineering) and my (Bertrand) views, and shouldn't be taken for granted as a roadmap or work in progress.
The first task here is to identify the parts of the CMS that represent our current "content engine", and what isn't. For instance, it would be a bit stupid to consider that users belong to a non relational DB. The fact that users are built with content is another issue when it comes to externalizing them. Then there is the model, what we can content classes and content structure. The principle itself is something we can't and won't get rid of, as it is one of the key features of eZ Publish (at least I think so, and I think most others do). Its flexibility and ease of use is something we must maintain, even though moving to Solr / KV / CouchDB / whatever implies new ways of exploiting this. The other thing, that comes on top of all of this, is that our Object Oriented model isn't fit _ yet _ for such a change. We need to refactor big parts of the CMS to account for that. And we are. But since we have a constraint of maintaining BC, it's not like we can just drop what we don't like and replace it with something else. This is where the new API (stay tuned at the conference on friday !) is entering the building. As you can see, it is far from being an easy topic, but we are fully aware of the benefits of these storage engines. And as an answer to Luc, yes, Solr is similar. It is queried using a fast HTTP interface, is fully scalable, and matches the features we need. Thanks to our experience with eZ Find, we have some heavy background knowledge about it, and are able to progress faster. My, this was a reply that goes in any possible direction :p -- Bertrand
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
