Luc Chase wrote: > "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. >
Might make for a very interesting extension! But this will work only 100% only if all attributes in all classes are indexed that could be used for attribute filters @bd: did you work on this already? would you see a community-driven extension implementing this as a boon or as a waste of time / hampering "official" progress? > > On 23 June 2010 22:03, Bertrand Dunogier <[email protected] <mailto:[email protected]>> > wrote: > > 2010/6/23 Luc Chase <[email protected] <mailto:[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
