Since we support multiple db systems such as Oracle etc., I thought everything went through ezpersistentobject. Well, I do strongly agree that we must keep the ability to create new content classes and relationships at run-time. I think this move is really a key step up for eZ. I'm very much looking forward to it.
-- Luc. On 23 June 2010 16:47, Gaetano Giunta <[email protected]> wrote: > 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 > -- Luc. M. +44.7939 00 29 32 T. +44.2071939840 / +44.7040901582 Writing can be either readable or precise, but not at the same time. - Betrand Russell
-- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
