Luc Chase <[email protected]> wrote on 23/06/2010 17:59: > Since we support multiple db systems such as Oracle etc., I thought > everything went through ezpersistentobject.
Not exactly. We have the ezdb layer that eases out differences between the supported databases, so it is quite easy to do direct db access. The eZP kernel does it in limited places, and uses sql syntax generic enough to run on all supported dbs. Extensions developed by the community are sometimes less respectful... > 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] <mailto:[email protected]>> wrote: > > Bertrand Dunogier <[email protected] <mailto:[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] <mailto:[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
