Of course, I understand what "transaction" means; have you guys been thinking 
some about what may happen if we transfer $123.45 from one banking account to 
another banking account, and MySQL forgets to index "decimal" during 
transaction, or DBA was weird and forgot to create an index? Absolutely nothing.

Why to embed "indexing" as a transaction dependency? Extremely weird idea. But 
I understand some selling points...


SOLR: it is faster than Lucene. Filtered queries run faster than traditional 
"AND" queries! And this is real selling point.



Thanks,

Fuad Efendi
+1 416-993-2060
http://www.linkedin.com/in/liferay

Tokenizer Inc.
http://www.tokenizer.ca/
Data Mining, Vertical Search


> -----Original Message-----
> From: Fuad Efendi [mailto:f...@efendi.ca]
> Sent: January-22-10 11:23 PM
> To: solr-user@lucene.apache.org
> Subject: RE: Solr vs. Compass
> 
> Yes, "transactional", I tried it: do we really need "transactional"?
> Even if "commit" takes 20 minutes?
> It's their "selling point" nothing more.
> HBase is not transactional, and it has specific use case; each tool has
> specific use case... in some cases Compass is the best!
> 
> Also, note that Compass (Hibernate) ((RDBMS)) use specific "business
> domain model" terms with relationships; huge overhead to convert
> "relational" into "object-oriented" (why for? Any advantages?)... Lucene
> does it behind-the-scenes: you don't have to worry that field "USA" (3
> characters) is repeated in few millions documents, and field "Canada" (6
> characters) in another few; no any "relational", it's done automatically
> without any Compass/Hibernate/Table(s)
> 
> 
> Don't think "relational".
> 
> I wrote this 2 years ago:
> http://www.theserverside.com/news/thread.tss?thread_id=50711#272351
> 
> 
> Fuad Efendi
> +1 416-993-2060
> http://www.tokenizer.ca/
> 
> 
> > -----Original Message-----
> > From: Uri Boness [mailto:ubon...@gmail.com]
> > Sent: January-21-10 11:35 AM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Solr vs. Compass
> >
> > In addition, the biggest appealing feature in Compass is that it's
> > transactional and therefore integrates well with your infrastructure
> > (Spring/EJB, Hibernate, JPA, etc...). This obviously is nice for some
> > systems (not very large scale ones) and the programming model is
> clean.
> > On the other hand, Solr scales much better and provides a load of
> > functionality that otherwise you'll have to custom build on top of
> > Compass/Lucene.
> >
> > Lukáš Vlček wrote:
> > > Hi,
> > >
> > > I think that these products do not compete directly that much, each
> > fit
> > > different business case. Can you tell us more about our specific
> > situation?
> > > What do you need to search and where your data is? (DB, Filesystem,
> > Web
> > > ...?)
> > >
> > > Solr provides some specific extensions which are not supported
> > directly by
> > > Lucene (faceted search, DisMax... etc) so if you need these then
> your
> > bet on
> > > Compass might not be perfect. On the other hand if you need to index
> > > persistent Java objects then Compass fits perfectly into this
> scenario
> > (and
> > > if you are using Spring and JPA then setting up search can be matter
> > of
> > > several modifications to configuration and annotations).
> > >
> > > Compass is more Hibernate search competitor (but Compass is not
> > limited to
> > > Hibernate only and is not even limited to DB content as well).
> > >
> > > Regards,
> > > Lukas
> > >
> > >
> > > On Thu, Jan 21, 2010 at 4:40 PM, Ken Lane (kenlane)
> > <kenl...@cisco.com>wrote:
> > >
> > >
> > >> We are knee-deep in a Solr project to provide a web services layer
> > >> between our Oracle DB's and a web front end to be named later  to
> > >> supplement our numerous Business Intelligence dashboards. Someone
> > from a
> > >> peer group questioned why we selected Solr rather than Compass to
> > start
> > >> development. The real reason is that we had not heard of Compass
> > until
> > >> that comment. Now I need to come up with a better answer.
> > >>
> > >>
> > >>
> > >> Does anyone out there have experience in both approaches who might
> be
> > >> able to give a quick compare and contrast?
> > >>
> > >>
> > >>
> > >> Thanks in advance,
> > >>
> > >> Ken
> > >>
> > >>
> > >>
> > >
> > >
> 



Reply via email to