Hi Robert
Given I've been a bit slow to respond, perhaps you've found a solution
already... but here's a few things to consider:
* There is no limit to MVAs - so your user limit should be fine. However,
attributes are loaded into memory while Sphinx is running - so the more data
you have in your attributes, the more RAM you'll need for Sphinx.
* The :joins option for search queries just gets passed along to the underlying
ActiveRecord find call when instantiating the search results - it has nothing
to do with the actual search query and Sphinx.
* There's also a join method for within define_index, but that's just for
association references, to force tables being joined to - useful if you're
creating some attributes or fields with SQL snippets, instead of normal column
references.
* You can use multiple filters in :with - but keep in mind the logic to join
them is AND, not OR - and that's not something you can change.
Hope this helps.
--
Pat
On 29/06/2010, at 4:38 PM, rbjarnason wrote:
> Hi Pat,
>
> Thanks for a quick answer :)
>
> Couple of follow up points.
>
> With a theoretical limit of about 2500 users and few hundred
> projects. Would the former approach be possible/practical/workable?
>
> Reason I'm asking is that we're being asked if it would be possible to
> add another layer of access control where each project would both have
> a project type and a client id and the ProjectAccess would then have
> (project_type_id, client_id, user_id).
>
> I guess it would be simpler to collect the user_ids in the index for
> each project with that extra access dimension.
>
> Our access filter would look something like this:
> named_scope :filtered, lambda {{ :joins=>"INNER JOIN project_access
> ON project_access.project_type_id = projects.project_type_id AND \
>
> project_access.client_id = projects.client_id",
> :conditions =>
> ["project_access.user_id = ?", Thread.current[:user_id]] }}
>
> I noticed that you've recently added a :join option to the code, which
> I gathered could be used in this case to collect the ids for the
> index, do you have any example snippets for using this feature?
>
> Or would it be possible somehow to combine the project_type_id and
> client_id in the second approach and search :with a combination of the
> two?
>
> Warm regards,
> Robert
>
> On Jun 29, 4:44 am, Pat Allan <[email protected]> wrote:
>> Hi Robert
>>
>> I guess there's two approaches here... you'll either want to store all the
>> user ids that have access to a given project:
>>
>> has project_type.project_accesses.user_id, :as => :user_ids
>>
>> However, if you're going to have a lot of users, this may not be the best
>> approach... I would recommend you store the project type id as an attribute
>> instead:
>>
>> has project_type_id
>>
>> Then, find out which project types a user has access to:
>>
>> project_type_ids = ProjectAccess.find(:all, :conditions => {:user_id =>
>> current_user.id}).collect { |access| access.project_type_id }
>>
>> And use that as a filter in the search:
>>
>> Project.search 'foo', :with => {:project_type_id => project_type_ids}
>>
>> Hope this helps.
>>
>> --
>> Pat
>>
>> On 29/06/2010, at 11:55 AM, rbjarnason wrote:
>>
>>
>>
>>> Hi,
>>
>>> I'm trying to implement search using Thinking Sphinx for Projects that
>>> have access control based on Project Types.
>>
>>> I have 4 tables I need to work with:
>>> * Project (included in search)
>>> * Project Type (included by association in search)
>>> * User (the logged in user)
>>> * Project Access (which has project_type_id, user_id)
>>
>>> When logged in, I would only like to return search results for
>>> projects of types that a given user has access to as defined in the
>>> Project Access table.
>>
>>> I've been looking at this post: "Limiting search results depending on
>>> authorization level" that has given me few clues but I'm still at a
>>> loss how I begin implementing this sort of access control using
>>> Thinking Sphinx.
>>> http://groups.google.com/group/thinking-sphinx/browse_thread/thread/4...
>>
>>> Any leads would be highly appreciated.
>>
>>> Warm regards,
>>> Robert Bjarnason
>>
>>> --
>>> 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
>>> athttp://groups.google.com/group/thinking-sphinx?hl=en.
>
> --
> 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.
>
--
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.
