Hi Doug
I don't think anyone's really paid attention to this before... so it's
not a known bug, but you're right, it should be fixed. MySQL will very
likely do the same thing, but everything's abstracted enough that you
won't be restructuring the raw SQL, but re-ordering method calls
instead. If you want to have a go at making a patch, would love to see
it :)
Cheers
--
Pat
On 25/01/2009, at 3:37 AM, Doug wrote:
>
> That's a mouthful, so I'll just show an example of what I mean:
>
> define_index do
> indexes [:address, amenities.name], :as => :full_text
> end
>
> where amenities is some variety of has_many association. In
> postgresql this produces the following sql in the config file:
>
> array_to_string(array_accum(COALESCE("properties"."address", '') || '
> ' || COALESCE("amenities"."name", '')), ' ')
>
> Which when run returns a string of the form: "address first_amenity
> address second_amenity address third_amenity" which while function
> ends up making a much larger index than is needed. The correct SQL
> would be:
>
> COALESCE("properties"."address", '') || ' ' || array_to_string
> (array_accum(COALESCE("amenities"."name", '')), ' ')
>
> which returns: "address first_amenity second_amenity third_amenity",
> what you'd expect. I haven't tried this on Mysql, but it looks like
> it might be doing the same thing.
>
> Has anyone else run into this? Is it a known bug? Can someone verify
> that this does the same thing in mysql? I'm happy to write up a
> patch, but I wanted to make sure I was on the right track and no one
> else is working on it right now.
>
> Thanks,
> Doug
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Thinking Sphinx" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/thinking-sphinx?hl=en
-~----------~----~----~----~------~----~------~--~---
