On Fri, Oct 11, 2013 at 1:05 PM, Thomas Mortagne <[email protected]> wrote: > On Fri, Oct 11, 2013 at 11:55 AM, Marius Dumitru Florea > <[email protected]> wrote: >> Hi devs, >> >> This is a very important question so think carefully. Let me explain: >> >> In XWiki (model) we have a few entity types. There are *wikis* which >> have *spaces* which have *documents*. A document can have *objects* >> and *attachments*. A document can also define a *class*. >> >> At the same time we like to say that in XWiki "everything is a >> document" because everything revolves around documents. The document >> is the central notion. >> >> We can query the database (using HQL or XWQL) for any of the >> previously mentioned entities but what should a Solr query return >> (semantically)? In other words: >> >> * are you searching for an object without caring about the document >> that holds the object? Same for an object property. >> * how often are you searching for an attachment without caring about >> the document that holds the attachment? >> * are you searching for a class or for the document that defines that class? >> * are you searching for a wiki without caring about the documents it >> contains? Same for a space. >> >> IMO the result of a Solr query should be, semantically, a list of >> documents. But maybe I'm wrong. >> >> ----------------------- >> Technical Details >> ----------------------- >> >> Unlike a relational database, Solr/Lucene index has a single 'table'. >> So normally you index a single entity type. Each row in the index >> represents an entity of that type. As a consequence the result of a >> Solr query is semantically a list of entities of that type. In our >> case the entity type is (naturally) *document*. >> >> If you want to index more entity types (e.g. index attachments and >> objects _separately_, not as part of a document) then, since there is >> only one 'table' in the index, you need to add a 'type' column that >> specifies the type of entity you have on each row (e.g. type=document, >> type=attachment, type=object etc.). The result of a Solr query is now, >> semantically, a list of different entity types, unless you filter by a >> specific type. It smells like a hack to me. >> >> Let's imagine what happens if we want to search for blog posts that >> has a specific tag. With the first approach this is easy because all >> the (indexed) information is on a single row. With the second approach >> this is considerably more complex because the information is spread on >> multiple rows: >> >> * one row with type=document for the blog post document >> * one row with type=object for the blog post object >> * one row with type=object for the tab object >> >> In a relational database when you have the information spread in >> multiple places (tables) you do joins. Fortunately (you would says) >> Solr supports joins. In this particular case we would have to perform >> 2 joins which means: >> >> index X index X index >> >> where X represents the cartesian product. The document name would be >> the join key. Pretty complex even before trying to write this in Solr >> query syntax.. >> >> So basically the question becomes: is it worth indexing more entities >> _separately_ instead of indexing just documents (with info about their >> objects and attachments) considering the complexity that it brings in >> writing Solr queries? Do we search for objects and attachments alone >> as separate entities often enough to justify this complexity? My >> answer is no. >
> Sounds good in theory but storing several entities in the same entry > has complexity of it's own that needs to be discussed before deciding. I agree. > > How do you plan to store several tag objects of the same document in a > single document entry for example ? I haven't thought very much but I was thinking about using multiValued="true" maybe in combination with dynamic fields. I need to think about this. Thanks, Marius > >> >> Thanks, >> Marius >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
