Thanks ,Peter . This very much seems to be the solution that I should be going forward with .Thanks for your time and clear explanation.
Regards Sujatha On Fri, Jun 17, 2011 at 2:49 PM, Peter Sturge <peter.stu...@gmail.com>wrote: > You'll need to be a bit careful using joins, as the performance hit > can be significant if you have lots of cross-referencing to do, which > I believe you would given your scenario. > > Your table could be setup to use the username as the key (for fast > lookup), then map these to your own data class or collection or > similar to hold your other information: products, expiry etc. > By using your own data class, it's then easy to extend it later if you > want to add additional parameters. (for example: HashMap<String, > MyDataClass>) > > When a search comes in, the user is looked up to retrieve the data > class, then its contents (as defined by you) is examined and the query > is processed/filtered appropriately. > > You'll need a bootstrap mechanism for populating the list in the first > place. One thing worth looking at is lazy loading - i.e. the first > time a user does a search (you lookup the user in the table, and it > isn't there), you load the data class (maybe from your DB, a file, or > index), then ad it to the table. This is good if you have 10's of > thousands or millions of users, but only a handful are actually > searching, some perhaps very rarely. > > If you do have millions of users, and your data class has heavy > requirements (e.g. many thousands of products + info etc.), you might > want to 'time-out' in-memory table entries, if the table gets really > huge - it depends on the usage of your system. (you can run a > synchronized cleanup thread to do this if you deemed it necessary). > > > On Fri, Jun 17, 2011 at 6:06 AM, Sujatha Arun <suja.a...@gmail.com> wrote: > > Alexey, > > > > Do you mean that we have current Index as it is and have a separate core > > which has only the user-id ,product-id relation and at while querying > ,do a > > join between the two cores based on the user-id. > > > > > > This would involve us to Index/delete the product as and when the user > > subscription for a product changes ,This would involve some amount of > > latency if the Indexing (we have a queue system for Indexing across the > > various instances) or deletion is delayed > > > > IF we want to go ahead with this solution ,We currently are using solr > 1.3 > > , so is this functionality available as a patch for solr 1.3?Would it be > > possible to do with a separate Index instead of a core ,then I can > create > > only one Index common for all our instances and then use this instance > to > > do the join. > > > > Thanks > > Sujatha > > > > On Thu, Jun 16, 2011 at 9:27 PM, Alexey Serba <ase...@gmail.com> wrote: > > > >> > So a search for a product once the user logs in and searches for only > the > >> > products that he has access to Will translate to something like this . > >> ,the > >> > product ids are obtained form the db for a particular user and can > run > >> > into n number. > >> > > >> > <search term> &fq=product_id(100 10001 ......n number) > >> > > >> > but we are currently running into too many Boolean expansion error .We > >> are > >> > not able to tie the user also into roles as each user is mainly any > one > >> who > >> > comes to site and purchases a product . > >> > >> I'm wondering if new trunk Solr join functionality can help here. > >> > >> * http://wiki.apache.org/solr/Join > >> > >> In theory you can index your products (product_id, ...) and > >> user_id-product many-to-many relation (user_product_id, user_id) into > >> signle/different cores and then do join, like > >> f=search terms&fq={!join from=product_id > to=user_product_id}user_id:10101 > >> > >> But I haven't tried that, so I'm just speculating. > >> > > >
