"we recommend replacing heavy content requests by solr searches ;) " So.... might it then be possible to have the eZ Find extension actually alter the way the standard template fetch functions work? i.e. if eZ Find is present fetches can work via Solr, without having to alter any fetch code.
On 23 June 2010 22:03, Bertrand Dunogier <[email protected]> wrote: > 2010/6/23 Luc Chase <[email protected]> > >> > Disadvantages >> >> > 1) slow >> I would expect a huge improvement on current performance and I very much >> doubt it would be slower. But if it is then, I would say do not do it. >> > > Well, everything's relative, including performances... there is no such > thing as pure performances as far as the database's concerned. Non-SQL DBs > will definitely be faster when it comes to listing using search criterias, > for instance. That is actually why we recommend replacing heavy content > requests by solr searches ;) > > But it doesn't mean such a DB would be faster for everything. I for one > thing it might be slower when inserting / updating content; such operations > are very commonly asynchronous, and this might also be an issue. > > All of this is perfectly manageable. With time... > > In any case, about replacing the current "content DB" (we should first > identify which parts of the DB are part of the content engine and which are > not...), yes, there is an abstraction layer. But unfortunately, we live in a > world where database / query abstraction is far from perfect, especially > back a few years ago. Refactoring all of this is planned, but parallel work > on such an integration will (or would) severely increase developement time. > And will also add up again when the public API is refactored. > > But yes, when it comes to extracting & rendering content, such a no-SQL DB > would probably be much more efficient. Not that much for UGC & social stuff > though... right ? > > -- > Bertrand > > -- 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
