Hello everyone,
I’m using multi-search to search in some attributes of two classes. One
of the attributes is the id of the customer. For each multi_search I
want to do a give the id of the current customer as a parameter. This
should only return results for the given customer.
My current code looks like this:
Folder.multi_search(@search_query, [Myfile])
I noticed in the API you can add options and find_options to this. How
do I use these parameters, so only results for a certain customer are
returned?
Thanks in advance.
Mischa
–
http://boxroom.rubyforge.org
Hi Mischa!
On Wed, Feb 28, 2007 at 09:58:18PM +0100, Mischa B. wrote:
I noticed in the API you can add options and find_options to this. How
do I use these parameters, so only results for a certain customer are
returned?
With aaf trunk you can do
Folder.multi_search(@search_query, [Myfile], {}, { :conditions => [
“customer_id=?”, @customer.id ] })
As there’s no way to specify per-model find_options, you need a
customer_id field in both models, MyFile and Folder. However it would
not be that hard to add a model dimension to the find_options hash for
multi_search (patches welcome ;-).
aaf 0.3.1 (stable) doesn’t support find_options with multi_search.
Cheers,
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
Hi Jens,
With aaf trunk you can do
Folder.multi_search(@search_query, [Myfile], {}, { :conditions => [
“customer_id=?”, @customer.id ] })
Thanks for your answer. When do you expect this to be in a stable
release?
I’m assuming the customer_id field needs to be indexed too for this to
work, is that correct?
Cheers,
Mischa.
–
http://boxroom.rubyforge.org
Thanks Jens,
I really appreciate your help.
no, the find_options are only used when fetching the results via active
record.
If you indexed the customer_id field you could just append
“+customer_id:#{normalize(@customer.id)}” to the ferret query string.
I have a few more questions.
At the moment I am indexing the customer_id too. Which one of these two
option would be better performance-wise?
(normalize should be a function that pads the customer id to a fixed
length string)
Why is it needed to pad the customer id to a fixed length string? I
tried it without the padding and that seems to work. In case it’s better
to do the padding; should I find the id with the longest length and add
spaces in front if the length of the customer_id I’m searching for is
smaller?
Thanks again!
Mischa.
–
http://boxroom.rubyforge.org
On Thu, Mar 01, 2007 at 01:22:01PM +0100, Mischa B. wrote:
Hi Jens,
With aaf trunk you can do
Folder.multi_search(@search_query, [Myfile], {}, { :conditions => [
“customer_id=?”, @customer.id ] })
Thanks for your answer. When do you expect this to be in a stable
release?
As I’m quite busy atm that might take a bit (2 or 3 weeks). However the
current trunk is not ‘unstable’ - it’s in a useable state and passes all
unit tests, so you should give it a try if you need that feature now.
I’m assuming the customer_id field needs to be indexed too for this to
work, is that correct?
no, the find_options are only used when fetching the results via active
record.
If you indexed the customer_id field you could just append
“+customer_id:#{normalize(@customer.id)}” to the ferret query string.
(normalize should be a function that pads the customer id to a fixed
length string)
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa
On Thu, Mar 01, 2007 at 09:01:51PM +0100, Mischa B. wrote:
I have a few more questions.
At the moment I am indexing the customer_id too. Which one of these two
option would be better performance-wise?
If there is exactly one customer per document, having the customer_id
indexed would be better. However the find_options are useful e.g. when
you have to do joins to select records a client may see.
(normalize should be a function that pads the customer id to a fixed
length string)
Why is it needed to pad the customer id to a fixed length string? I
tried it without the padding and that seems to work. In case it’s better
to do the padding; should I find the id with the longest length and add
spaces in front if the length of the customer_id I’m searching for is
smaller?
I’m not sure about the normalizing thing, possible you don’t need it.
But the field has to be untokenized. Afair the padding was only needed
in earlier versions of ferret for sorting by fields with numeric
contents - even there it’s not needed any more.
cheers,
Jens
–
Jens Krämer
webit! Gesellschaft für neue Medien mbH
Schnorrstraße 76 | 01069 Dresden
Telefon +49 351 46766-0 | Telefax +49 351 46766-66
[email protected] | www.webit.de
Amtsgericht Dresden | HRB 15422
GF Sven Haubold, Hagen Malessa