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. >> >
