Bertrand Dunogier <[email protected]> wrote on 23/06/2010 17:40: > 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.
While it is far from being an easy challenge, the fact that eZ was built since day 1 on a model where objects are persisted to the db via a specific mapping (the ezpersistentobject) is, I think, what will in the end make the switch possible at all. Besides rewriting huge parts of ezcontentobject* and trying to coerce ezpersistentobject to become a php interface rather than an actual class, am I right in stating that one of the initial steps to achieve the final goal of the conversion is to hunt every direct db-access in the codebase and replace it with an ezpersistentobject method call? > 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
