Abandoning Searchable Plugin

[Dustin Whitney]

My team has decided to abandon the searchable plugin in favor of solr from apache.  I think the searchable plugin has great potential, so I thought I'd share some constructive criticism to help it along.

The number one problem was the documentation doesn't seem to match up with the implementation (note that the wiki contains formatting bugs that make all documentation for grails a bit difficult to read at the moment).  This made the plugin appear to be really buggy, when it many in fact not be buggy at all, but I have no way of knowing because I can't get a lot of things working.  For one, the documentation implies that something simple like a one-to-one or one-to-many relationship should work out of the box.  Like for example Book.search("words in a chapter that are in a one-to-many relationship") should yield hits, but it does not.  Instead I spent several hours figuring out how to make that work, and ran into many road blocks and misdirections that came straight out of the documentation, like for example "embedded = chapters" isn't correct any more, but it's still there.

The number two reason, and probably the more important reason, is that there is no support for clustering.  I guess you can store your index in a database, but that kinda-sorta, from a performance POV, defeats the purpose of lucene, doesn't it?  The only solution I could find involved using Terracotta and hacking the Grails source code.  There is absolutely no way I'm going to get buy in if it involves hacking Grails source.  I'd imagine any site, beyond a hobby site, is going to require some clustering.  It needs to be supported out of the box.  Solr does that, so we're switching. 

That said, the development time involved in the switch to Solr is going to increase dramatically, and I want to encourage development on the searchable plugin as I think it's a fantastic addition to the grails suite.

-Dustin

I tend to agree with you. At first the Searchable Plugin seems great,
unfortunately as my application grew in complexity I am having more
and more problems with it. As you say the documentation is lacking.

I think what should be done with the searchable plugin is favor a
total integration with the underlying Compass technology. In the same
way as Grails: if GORM is not enough for you, you can go one level
down and map with Hibernate. That's great. Same applies for Spring.

So far I have been able to achieve what I want with Compass, but this
greatly diminishes the interest of the plugin.

Anyway, the main problem is development time; with more development
time the issues would be resolved.

Solr, Hibernate Search all look great too and if I encounter too much
problems with Compass/ Searchable I will also switch.

Jean-Noel

On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney <dustin.whitney@...> wrote:

> My team has decided to abandon the searchable plugin in favor of solr from
> apache.  I think the searchable plugin has great potential, so I thought I'd
> share some constructive criticism to help it along.
>
> The number one problem was the documentation doesn't seem to match up with
> the implementation (note that the wiki contains formatting bugs that make
> all documentation for grails a bit difficult to read at the moment).  This
> made the plugin appear to be really buggy, when it many in fact not be buggy
> at all, but I have no way of knowing because I can't get a lot of things
> working.  For one, the documentation implies that something simple like a
> one-to-one or one-to-many relationship should work out of the box.  Like for
> example Book.search("words in a chapter that are in a one-to-many
> relationship") should yield hits, but it does not.  Instead I spent several
> hours figuring out how to make that work, and ran into many road blocks and
> misdirections that came straight out of the documentation, like for example
> "embedded = chapters" isn't correct any more, but it's still there.
>
> The number two reason, and probably the more important reason, is that there
> is no support for clustering.  I guess you can store your index in a
> database, but that kinda-sorta, from a performance POV, defeats the purpose
> of lucene, doesn't it?  The only solution I could find involved using
> Terracotta and hacking the Grails source code.  There is absolutely no way
> I'm going to get buy in if it involves hacking Grails source.  I'd imagine
> any site, beyond a hobby site, is going to require some clustering.  It
> needs to be supported out of the box.  Solr does that, so we're switching.
>
> That said, the development time involved in the switch to Solr is going to
> increase dramatically, and I want to encourage development on the searchable
> plugin as I think it's a fantastic addition to the grails suite.
>
> -Dustin
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Darryl Pentz]

Yeah, I can understand your frustration that led you to switch to Solr. I also found that the documentation differed with the reality.

I don't for one moment want to seem unappreciative of the Searchable plugin. One look at its source code will give you immediate appreciation for all the hard work Maurice has invested in it. It was unfortunate for me that a) Maurice was away at the time that I started incorporating the Searchable plugin into my app - and seems to not be around much anymore these days too and b) the move to a Grails-based grails.org happened around the same time I needed to investigate the Searchable features more intimately, which has affected the documentation.

Unfortunately all that good intention and appreciation doesn't help me explain to my boss why feature X isn't working, so at some point one has to make a decision. So far I've been fortunate that I've been able to get past most of the obstacles, but the lack of clustering is one I wasn't aware of and may come back to bite me in the end. I currently don't need clustering, even though it's not a hobby project ;-) but who knows what requirements lie in wait in the future.

I hope (and pray) that Maurice will be able to continue work on Searchable with time. I would love to myself but after looking at his code, I don't consider myself capable of continuing the excellent standard he's set.

Regards,
Darryl

----- Original Message ----
From: Jean-Noël Rivasseau <elvanor@...>
To: user@...
Sent: Wednesday, June 4, 2008 6:50:32 PM
Subject: Re: [grails-user] Abandoning Searchable Plugin

I tend to agree with you. At first the Searchable Plugin seems great,
unfortunately as my application grew in complexity I am having more
and more problems with it. As you say the documentation is lacking.

I think what should be done with the searchable plugin is favor a
total integration with the underlying Compass technology. In the same
way as Grails: if GORM is not enough for you, you can go one level
down and map with Hibernate. That's great. Same applies for Spring.

So far I have been able to achieve what I want with Compass, but this
greatly diminishes the interest of the plugin.

Anyway, the main problem is development time; with more development
time the issues would be resolved.

Solr, Hibernate Search all look great too and if I encounter too much
problems with Compass/ Searchable I will also switch.

Jean-Noel

On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney <dustin.whitney@...> wrote:

> My team has decided to abandon the searchable plugin in favor of solr from
> apache.  I think the searchable plugin has great potential, so I thought I'd
> share some constructive criticism to help it along.
>
> The number one problem was the documentation doesn't seem to match up with
> the implementation (note that the wiki contains formatting bugs that make
> all documentation for grails a bit difficult to read at the moment).  This
> made the plugin appear to be really buggy, when it many in fact not be buggy
> at all, but I have no way of knowing because I can't get a lot of things
> working.  For one, the documentation implies that something simple like a
> one-to-one or one-to-many relationship should work out of the box.  Like for
> example Book.search("words in a chapter that are in a one-to-many
> relationship") should yield hits, but it does not.  Instead I spent several
> hours figuring out how to make that work, and ran into many road blocks and
> misdirections that came straight out of the documentation, like for example
> "embedded = chapters" isn't correct any more, but it's still there.
>
> The number two reason, and probably the more important reason, is that there
> is no support for clustering.  I guess you can store your index in a
> database, but that kinda-sorta, from a performance POV, defeats the purpose
> of lucene, doesn't it?  The only solution I could find involved using
> Terracotta and hacking the Grails source code.  There is absolutely no way
> I'm going to get buy in if it involves hacking Grails source.  I'd imagine
> any site, beyond a hobby site, is going to require some clustering.  It
> needs to be supported out of the box.  Solr does that, so we're switching.
>
> That said, the development time involved in the switch to Solr is going to
> increase dramatically, and I want to encourage development on the searchable
> plugin as I think it's a fantastic addition to the grails suite.
>
> -Dustin
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

Mike got it clustering with terracotta -
http://mike.brevoort.com/2008/01/29/terracotta-1-grails-searchable-pluginme-1/

Cheers

On Wed, Jun 4, 2008 at 7:10 PM, Darryl Pentz <djpentz@...> wrote:

> Yeah, I can understand your frustration that led you to switch to Solr. I also found that the documentation differed with the reality.
>
> I don't for one moment want to seem unappreciative of the Searchable plugin. One look at its source code will give you immediate appreciation for all the hard work Maurice has invested in it. It was unfortunate for me that a) Maurice was away at the time that I started incorporating the Searchable plugin into my app - and seems to not be around much anymore these days too and b) the move to a Grails-based grails.org happened around the same time I needed to investigate the Searchable features more intimately, which has affected the documentation.
>
> Unfortunately all that good intention and appreciation doesn't help me explain to my boss why feature X isn't working, so at some point one has to make a decision. So far I've been fortunate that I've been able to get past most of the obstacles, but the lack of clustering is one I wasn't aware of and may come back to bite me in the end. I currently don't need clustering, even though it's not a hobby project ;-) but who knows what requirements lie in wait in the future.
>
> I hope (and pray) that Maurice will be able to continue work on Searchable with time. I would love to myself but after looking at his code, I don't consider myself capable of continuing the excellent standard he's set.
>
> Regards,
> Darryl
>
> ----- Original Message ----
> From: Jean-Noël Rivasseau <elvanor@...>
> To: user@...
> Sent: Wednesday, June 4, 2008 6:50:32 PM
> Subject: Re: [grails-user] Abandoning Searchable Plugin
>
> I tend to agree with you. At first the Searchable Plugin seems great,
> unfortunately as my application grew in complexity I am having more
> and more problems with it. As you say the documentation is lacking.
>
> I think what should be done with the searchable plugin is favor a
> total integration with the underlying Compass technology. In the same
> way as Grails: if GORM is not enough for you, you can go one level
> down and map with Hibernate. That's great. Same applies for Spring.
>
> So far I have been able to achieve what I want with Compass, but this
> greatly diminishes the interest of the plugin.
>
> Anyway, the main problem is development time; with more development
> time the issues would be resolved.
>
> Solr, Hibernate Search all look great too and if I encounter too much
> problems with Compass/ Searchable I will also switch.
>
> Jean-Noel
>
> On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney <dustin.whitney@...> wrote:
>> My team has decided to abandon the searchable plugin in favor of solr from
>> apache.  I think the searchable plugin has great potential, so I thought I'd
>> share some constructive criticism to help it along.
>>
>> The number one problem was the documentation doesn't seem to match up with
>> the implementation (note that the wiki contains formatting bugs that make
>> all documentation for grails a bit difficult to read at the moment).  This
>> made the plugin appear to be really buggy, when it many in fact not be buggy
>> at all, but I have no way of knowing because I can't get a lot of things
>> working.  For one, the documentation implies that something simple like a
>> one-to-one or one-to-many relationship should work out of the box.  Like for
>> example Book.search("words in a chapter that are in a one-to-many
>> relationship") should yield hits, but it does not.  Instead I spent several
>> hours figuring out how to make that work, and ran into many road blocks and
>> misdirections that came straight out of the documentation, like for example
>> "embedded = chapters" isn't correct any more, but it's still there.
>>
>> The number two reason, and probably the more important reason, is that there
>> is no support for clustering.  I guess you can store your index in a
>> database, but that kinda-sorta, from a performance POV, defeats the purpose
>> of lucene, doesn't it?  The only solution I could find involved using
>> Terracotta and hacking the Grails source code.  There is absolutely no way
>> I'm going to get buy in if it involves hacking Grails source.  I'd imagine
>> any site, beyond a hobby site, is going to require some clustering.  It
>> needs to be supported out of the box.  Solr does that, so we're switching.
>>
>> That said, the development time involved in the switch to Solr is going to
>> increase dramatically, and I want to encourage development on the searchable
>> plugin as I think it's a fantastic addition to the grails suite.
>>
>> -Dustin
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Dustin Whitney]

Graeme,

that's the solution that involved hacking the Grails source code.  You asked him a question in the comments, to which he responded with a question that you never responded back to.  Perhaps you could take the opportunity now?

-Dustin

On Wed, Jun 4, 2008 at 3:54 PM, Graeme Rocher <graeme@...> wrote:

Mike got it clustering with terracotta -
http://mike.brevoort.com/2008/01/29/terracotta-1-grails-searchable-pluginme-1/

Cheers

On Wed, Jun 4, 2008 at 7:10 PM, Darryl Pentz <djpentz@...> wrote:
> Yeah, I can understand your frustration that led you to switch to Solr. I also found that the documentation differed with the reality.
>
> I don't for one moment want to seem unappreciative of the Searchable plugin. One look at its source code will give you immediate appreciation for all the hard work Maurice has invested in it. It was unfortunate for me that a) Maurice was away at the time that I started incorporating the Searchable plugin into my app - and seems to not be around much anymore these days too and b) the move to a Grails-based grails.org happened around the same time I needed to investigate the Searchable features more intimately, which has affected the documentation.
>
> Unfortunately all that good intention and appreciation doesn't help me explain to my boss why feature X isn't working, so at some point one has to make a decision. So far I've been fortunate that I've been able to get past most of the obstacles, but the lack of clustering is one I wasn't aware of and may come back to bite me in the end. I currently don't need clustering, even though it's not a hobby project ;-) but who knows what requirements lie in wait in the future.
>
> I hope (and pray) that Maurice will be able to continue work on Searchable with time. I would love to myself but after looking at his code, I don't consider myself capable of continuing the excellent standard he's set.
>
> Regards,
> Darryl
>
> ----- Original Message ----
> From: Jean-Noël Rivasseau <elvanor@...>
> To: user@...
> Sent: Wednesday, June 4, 2008 6:50:32 PM
> Subject: Re: [grails-user] Abandoning Searchable Plugin
>
> I tend to agree with you. At first the Searchable Plugin seems great,
> unfortunately as my application grew in complexity I am having more
> and more problems with it. As you say the documentation is lacking.
>
> I think what should be done with the searchable plugin is favor a
> total integration with the underlying Compass technology. In the same
> way as Grails: if GORM is not enough for you, you can go one level
> down and map with Hibernate. That's great. Same applies for Spring.
>
> So far I have been able to achieve what I want with Compass, but this
> greatly diminishes the interest of the plugin.
>
> Anyway, the main problem is development time; with more development
> time the issues would be resolved.
>
> Solr, Hibernate Search all look great too and if I encounter too much
> problems with Compass/ Searchable I will also switch.
>
> Jean-Noel
>
> On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney <dustin.whitney@...> wrote:
>> My team has decided to abandon the searchable plugin in favor of solr from
>> apache.  I think the searchable plugin has great potential, so I thought I'd
>> share some constructive criticism to help it along.
>>
>> The number one problem was the documentation doesn't seem to match up with
>> the implementation (note that the wiki contains formatting bugs that make
>> all documentation for grails a bit difficult to read at the moment).  This
>> made the plugin appear to be really buggy, when it many in fact not be buggy
>> at all, but I have no way of knowing because I can't get a lot of things
>> working.  For one, the documentation implies that something simple like a
>> one-to-one or one-to-many relationship should work out of the box.  Like for
>> example Book.search("words in a chapter that are in a one-to-many
>> relationship") should yield hits, but it does not.  Instead I spent several
>> hours figuring out how to make that work, and ran into many road blocks and
>> misdirections that came straight out of the documentation, like for example
>> "embedded = chapters" isn't correct any more, but it's still there.
>>
>> The number two reason, and probably the more important reason, is that there
>> is no support for clustering.  I guess you can store your index in a
>> database, but that kinda-sorta, from a performance POV, defeats the purpose
>> of lucene, doesn't it?  The only solution I could find involved using
>> Terracotta and hacking the Grails source code.  There is absolutely no way
>> I'm going to get buy in if it involves hacking Grails source.  I'd imagine
>> any site, beyond a hobby site, is going to require some clustering.  It
>> needs to be supported out of the box.  Solr does that, so we're switching.
>>
>> That said, the development time involved in the switch to Solr is going to
>> increase dramatically, and I want to encourage development on the searchable
>> plugin as I think it's a fantastic addition to the grails suite.
>>
>> -Dustin
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Daniel Honig]

Well I'd say its probably worth raising a Jira issue to see if the code can be made extensible without being "hacked".

-dh

On Wed, Jun 4, 2008 at 4:13 PM, Dustin Whitney <dustin.whitney@...> wrote:

Graeme,

that's the solution that involved hacking the Grails source code.  You asked him a question in the comments, to which he responded with a question that you never responded back to.  Perhaps you could take the opportunity now?

-Dustin

On Wed, Jun 4, 2008 at 3:54 PM, Graeme Rocher <graeme@...> wrote:

Mike got it clustering with terracotta -
http://mike.brevoort.com/2008/01/29/terracotta-1-grails-searchable-pluginme-1/

Cheers

On Wed, Jun 4, 2008 at 7:10 PM, Darryl Pentz <djpentz@...> wrote:
> Yeah, I can understand your frustration that led you to switch to Solr. I also found that the documentation differed with the reality.
>
> I don't for one moment want to seem unappreciative of the Searchable plugin. One look at its source code will give you immediate appreciation for all the hard work Maurice has invested in it. It was unfortunate for me that a) Maurice was away at the time that I started incorporating the Searchable plugin into my app - and seems to not be around much anymore these days too and b) the move to a Grails-based grails.org happened around the same time I needed to investigate the Searchable features more intimately, which has affected the documentation.
>
> Unfortunately all that good intention and appreciation doesn't help me explain to my boss why feature X isn't working, so at some point one has to make a decision. So far I've been fortunate that I've been able to get past most of the obstacles, but the lack of clustering is one I wasn't aware of and may come back to bite me in the end. I currently don't need clustering, even though it's not a hobby project ;-) but who knows what requirements lie in wait in the future.
>
> I hope (and pray) that Maurice will be able to continue work on Searchable with time. I would love to myself but after looking at his code, I don't consider myself capable of continuing the excellent standard he's set.
>
> Regards,
> Darryl
>
> ----- Original Message ----
> From: Jean-Noël Rivasseau <elvanor@...>
> To: user@...
> Sent: Wednesday, June 4, 2008 6:50:32 PM
> Subject: Re: [grails-user] Abandoning Searchable Plugin
>
> I tend to agree with you. At first the Searchable Plugin seems great,
> unfortunately as my application grew in complexity I am having more
> and more problems with it. As you say the documentation is lacking.
>
> I think what should be done with the searchable plugin is favor a
> total integration with the underlying Compass technology. In the same
> way as Grails: if GORM is not enough for you, you can go one level
> down and map with Hibernate. That's great. Same applies for Spring.
>
> So far I have been able to achieve what I want with Compass, but this
> greatly diminishes the interest of the plugin.
>
> Anyway, the main problem is development time; with more development
> time the issues would be resolved.
>
> Solr, Hibernate Search all look great too and if I encounter too much
> problems with Compass/ Searchable I will also switch.
>
> Jean-Noel
>
> On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney <dustin.whitney@...> wrote:
>> My team has decided to abandon the searchable plugin in favor of solr from
>> apache.  I think the searchable plugin has great potential, so I thought I'd
>> share some constructive criticism to help it along.
>>
>> The number one problem was the documentation doesn't seem to match up with
>> the implementation (note that the wiki contains formatting bugs that make
>> all documentation for grails a bit difficult to read at the moment).  This
>> made the plugin appear to be really buggy, when it many in fact not be buggy
>> at all, but I have no way of knowing because I can't get a lot of things
>> working.  For one, the documentation implies that something simple like a
>> one-to-one or one-to-many relationship should work out of the box.  Like for
>> example Book.search("words in a chapter that are in a one-to-many
>> relationship") should yield hits, but it does not.  Instead I spent several
>> hours figuring out how to make that work, and ran into many road blocks and
>> misdirections that came straight out of the documentation, like for example
>> "embedded = chapters" isn't correct any more, but it's still there.
>>
>> The number two reason, and probably the more important reason, is that there
>> is no support for clustering.  I guess you can store your index in a
>> database, but that kinda-sorta, from a performance POV, defeats the purpose
>> of lucene, doesn't it?  The only solution I could find involved using
>> Terracotta and hacking the Grails source code.  There is absolutely no way
>> I'm going to get buy in if it involves hacking Grails source.  I'd imagine
>> any site, beyond a hobby site, is going to require some clustering.  It
>> needs to be supported out of the box.  Solr does that, so we're switching.
>>
>> That said, the development time involved in the switch to Solr is going to
>> increase dramatically, and I want to encourage development on the searchable
>> plugin as I think it's a fantastic addition to the grails suite.
>>
>> -Dustin
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

It could be done quite easily by writing a terracota plugin that does
what Mike's hack does and then making sure this plugin loads before
the searchable plugin

Cheers

On Wed, Jun 4, 2008 at 9:13 PM, Dustin Whitney <dustin.whitney@...> wrote:

> Graeme,
>
> that's the solution that involved hacking the Grails source code.  You asked
> him a question in the comments, to which he responded with a question that
> you never responded back to.  Perhaps you could take the opportunity now?
>
> -Dustin
>
> On Wed, Jun 4, 2008 at 3:54 PM, Graeme Rocher <graeme@...> wrote:
>>
>> Mike got it clustering with terracotta -
>>
>> http://mike.brevoort.com/2008/01/29/terracotta-1-grails-searchable-pluginme-1/
>>
>> Cheers
>>
>> On Wed, Jun 4, 2008 at 7:10 PM, Darryl Pentz <djpentz@...> wrote:
>> > Yeah, I can understand your frustration that led you to switch to Solr.
>> > I also found that the documentation differed with the reality.
>> >
>> > I don't for one moment want to seem unappreciative of the Searchable
>> > plugin. One look at its source code will give you immediate appreciation for
>> > all the hard work Maurice has invested in it. It was unfortunate for me that
>> > a) Maurice was away at the time that I started incorporating the Searchable
>> > plugin into my app - and seems to not be around much anymore these days too
>> > and b) the move to a Grails-based grails.org happened around the same time I
>> > needed to investigate the Searchable features more intimately, which has
>> > affected the documentation.
>> >
>> > Unfortunately all that good intention and appreciation doesn't help me
>> > explain to my boss why feature X isn't working, so at some point one has to
>> > make a decision. So far I've been fortunate that I've been able to get past
>> > most of the obstacles, but the lack of clustering is one I wasn't aware of
>> > and may come back to bite me in the end. I currently don't need clustering,
>> > even though it's not a hobby project ;-) but who knows what requirements lie
>> > in wait in the future.
>> >
>> > I hope (and pray) that Maurice will be able to continue work on
>> > Searchable with time. I would love to myself but after looking at his code,
>> > I don't consider myself capable of continuing the excellent standard he's
>> > set.
>> >
>> > Regards,
>> > Darryl
>> >
>> > ----- Original Message ----
>> > From: Jean-Noël Rivasseau <elvanor@...>
>> > To: user@...
>> > Sent: Wednesday, June 4, 2008 6:50:32 PM
>> > Subject: Re: [grails-user] Abandoning Searchable Plugin
>> >
>> > I tend to agree with you. At first the Searchable Plugin seems great,
>> > unfortunately as my application grew in complexity I am having more
>> > and more problems with it. As you say the documentation is lacking.
>> >
>> > I think what should be done with the searchable plugin is favor a
>> > total integration with the underlying Compass technology. In the same
>> > way as Grails: if GORM is not enough for you, you can go one level
>> > down and map with Hibernate. That's great. Same applies for Spring.
>> >
>> > So far I have been able to achieve what I want with Compass, but this
>> > greatly diminishes the interest of the plugin.
>> >
>> > Anyway, the main problem is development time; with more development
>> > time the issues would be resolved.
>> >
>> > Solr, Hibernate Search all look great too and if I encounter too much
>> > problems with Compass/ Searchable I will also switch.
>> >
>> > Jean-Noel
>> >
>> > On Wed, Jun 4, 2008 at 6:14 PM, Dustin Whitney
>> > <dustin.whitney@...> wrote:
>> >> My team has decided to abandon the searchable plugin in favor of solr
>> >> from
>> >> apache.  I think the searchable plugin has great potential, so I
>> >> thought I'd
>> >> share some constructive criticism to help it along.
>> >>
>> >> The number one problem was the documentation doesn't seem to match up
>> >> with
>> >> the implementation (note that the wiki contains formatting bugs that
>> >> make
>> >> all documentation for grails a bit difficult to read at the moment).
>> >>  This
>> >> made the plugin appear to be really buggy, when it many in fact not be
>> >> buggy
>> >> at all, but I have no way of knowing because I can't get a lot of
>> >> things
>> >> working.  For one, the documentation implies that something simple like
>> >> a
>> >> one-to-one or one-to-many relationship should work out of the box.
>> >>  Like for
>> >> example Book.search("words in a chapter that are in a one-to-many
>> >> relationship") should yield hits, but it does not.  Instead I spent
>> >> several
>> >> hours figuring out how to make that work, and ran into many road blocks
>> >> and
>> >> misdirections that came straight out of the documentation, like for
>> >> example
>> >> "embedded = chapters" isn't correct any more, but it's still there.
>> >>
>> >> The number two reason, and probably the more important reason, is that
>> >> there
>> >> is no support for clustering.  I guess you can store your index in a
>> >> database, but that kinda-sorta, from a performance POV, defeats the
>> >> purpose
>> >> of lucene, doesn't it?  The only solution I could find involved using
>> >> Terracotta and hacking the Grails source code.  There is absolutely no
>> >> way
>> >> I'm going to get buy in if it involves hacking Grails source.  I'd
>> >> imagine
>> >> any site, beyond a hobby site, is going to require some clustering.  It
>> >> needs to be supported out of the box.  Solr does that, so we're
>> >> switching.
>> >>
>> >> That said, the development time involved in the switch to Solr is going
>> >> to
>> >> increase dramatically, and I want to encourage development on the
>> >> searchable
>> >> plugin as I think it's a fantastic addition to the grails suite.
>> >>
>> >> -Dustin
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list, please visit:
>> >
>> >    http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>>
>>
>> --
>> Graeme Rocher
>> Grails Project Lead
>> G2One, Inc. Chief Technology Officer
>> http://www.g2one.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Sey]

I've been interested to use Solr in grails but looking around there is not clear path to start.  Perhaps you can write up your experience on Solr+Grails? It'd be very helpful.

On Thu, Jun 5, 2008 at 12:14 AM, Dustin Whitney <dustin.whitney@...> wrote:

My team has decided to abandon the searchable plugin in favor of solr from apache.  I think the searchable plugin has great potential, so I thought I'd share some constructive criticism to help it along.

The number one problem was the documentation doesn't seem to match up with the implementation (note that the wiki contains formatting bugs that make all documentation for grails a bit difficult to read at the moment).  This made the plugin appear to be really buggy, when it many in fact not be buggy at all, but I have no way of knowing because I can't get a lot of things working.  For one, the documentation implies that something simple like a one-to-one or one-to-many relationship should work out of the box.  Like for example Book.search("words in a chapter that are in a one-to-many relationship") should yield hits, but it does not.  Instead I spent several hours figuring out how to make that work, and ran into many road blocks and misdirections that came straight out of the documentation, like for example "embedded = chapters" isn't correct any more, but it's still there.

The number two reason, and probably the more important reason, is that there is no support for clustering.  I guess you can store your index in a database, but that kinda-sorta, from a performance POV, defeats the purpose of lucene, doesn't it?  The only solution I could find involved using Terracotta and hacking the Grails source code.  There is absolutely no way I'm going to get buy in if it involves hacking Grails source.  I'd imagine any site, beyond a hobby site, is going to require some clustering.  It needs to be supported out of the box.  Solr does that, so we're switching. 

That said, the development time involved in the switch to Solr is going to increase dramatically, and I want to encourage development on the searchable plugin as I think it's a fantastic addition to the grails suite.

-Dustin

--

Blogging Seymour Cakes
http://seymores.blogspot.com

[Brad Whitaker]

I'd be interested in this as well. I'm considering using Solr with my Grails app due to Solr's support of faceted search.

Seymour Cakes-2 wrote:

I've been interested to use Solr in grails but looking around there is not
clear path to start.  Perhaps you can write up your experience on
Solr+Grails? It'd be very helpful.

[Konstantyn Smirnov]

Jean-Noël Rivasseau-3 wrote:

At first the Searchable Plugin seems great,
unfortunately as my application grew in complexity I am having more
and more problems with it.

I crossed this line 2 times recently. From my PoV the problem lies not in the Plugin itself, but rather in Compass's own restrictions, which becomes too tight with the time.
At the very beginning the Compass/Searchable seem to be ok, but later you face obstacles, you cannot nicely overcome.

As a result, I had no other way than abandoning Compass for different really simple reasons in favor of the direct Lucene.

A simple example, which led to plugin removal, was following:

I have 2 classes like:

class Core {

  Date date

  Set<LocalizedInfo> localizedContents

}

class LocalizedInfo {

  String name

  String lang

  String text

}

So each Core can contain a collection of LocalizedInfo's, each of those are language-specific.

In Compass I would have to create locale-specific "marker" classes and mappings for them, like LocalizedInfoEnglish and LocalizedInfoGerman, which is anything but "groovy". The worst part is, that if I suddenly need a LocalizedInfoSpanish, I would have to redeploy and restart the whole app!

I built a service to index the objects, and it's smaller, that the SearchableConfiguration.groovy!
Now I can index any number of LocalizedInfo's in any language and search among them, using plain Lucene and Groovy with no additional complexity levels.

The only thing I kinda miss now is Searchable's QueryBuilder. It would be great, if Maurice or someone else publish it as a stand-alone module.

I think you could do it with Compass/Searchable quite easily. Whenever
you want to make a search, specify the query as lang:en
text:searchedtext. Would that not work?

Personnally I have exactly the same user case as yours, except I
modeled my data model with a Map <String, String> for the localized
contents (eg, the key of the map is the locale, the value is the
localized content). Compass handles this just fine (actually, it needs
a Map converter but Maurice Nicholson wrote one, and anyway writing
this converter is not hard).

As I already said, biggest problem with the plugin right now is
documentation + lack of development time I guess. The plugin makes
Grails non reloadable which is actually very bad :(

Jean-Noel

>
> I have 2 classes like:
>
> class Core {
>
>  Date date
>
>  Set<LocalizedInfo> localizedContents
>
> }
>
> class LocalizedInfo {
>
>  String name
>
>  String lang
>
>  String text
>
> }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Konstantyn Smirnov]

Jean-Noël Rivasseau-3 wrote:

I think you could do it with Compass/Searchable quite easily. Whenever
you want to make a search, specify the query as lang:en
text:searchedtext. Would that not work?

For searching yes, but not in OSEM mappings: I coulnd't find a way of associating different analyzers to the same field of the same class.

[Daniel Honig]

One of my current concerns is what if I need finer grained control of indexing than what the plugin offers?  For example the ability to conditionally add an object to the index based on a condition across fields that may depend on each others state
   "if x=1 and y=2 then index"

Also would love to see if anyone has examples of what they feel are very complex queries.

But I'd say from a bang for the buck perspective the plugin is very impressive.

On Sun, Jun 22, 2008 at 6:11 AM, Jean-Noël Rivasseau <elvanor@...> wrote:

I think you could do it with Compass/Searchable quite easily. Whenever
you want to make a search, specify the query as lang:en
text:searchedtext. Would that not work?

Personnally I have exactly the same user case as yours, except I
modeled my data model with a Map <String, String> for the localized
contents (eg, the key of the map is the locale, the value is the
localized content). Compass handles this just fine (actually, it needs
a Map converter but Maurice Nicholson wrote one, and anyway writing
this converter is not hard).

As I already said, biggest problem with the plugin right now is
documentation + lack of development time I guess. The plugin makes
Grails non reloadable which is actually very bad :(

Jean-Noel

>
> I have 2 classes like:
>
> class Core {
>
>  Date date
>
>  Set<LocalizedInfo> localizedContents
>
> }
>
> class LocalizedInfo {
>
>  String name
>
>  String lang
>
>  String text
>
> }

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email