Hi Nick, > -----Original Message----- > From: Nick Reddel [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 4. Februar 2004 12:41 > To: 'Slide Developers Mailing List' > Subject: RE: proposal: integrate indexing - search > > > Notes on core patches> > > On the "bloating" issue with Namespace etc, just remember that the > indexer and the query execution sections both (at present) need > package-level access to the RDBMS store, or adapter, so they can get a > connection to the database. > > Also, because lock and acl resolution are the main anti-optimisers > (because they're hierarchical), it could well be useful that the query > execution engine have access to the store's caches, so it can check > there for lock/acl info before running potentially expensive > sql queries >
Locking should be no problem, as locked resources may be read. If your implementation stores ACL in the same store as the properties, you might optimise a query taking ACL into account. But you then re-implement logic in the search engine, which already has its place in the security helper. Your approach couples security and property store, which boosts performance for your special scenario, but is not feasable as a generic approach for slide. > At the moment, my implementation uses (!!) reflection to get these > things. It might clarify things if I send things out (next couple of > days), and then make the changes ... basically allowing > formal access to > the necessary methods. I was thinking of some sort of "IndexToken" (or > just amplify searchToken) that allows real, non-helper access to the > caches and rdbms connection. > Great! > Also, a few weeks back I outlined a different set of ideas for > domain.xml to those in indexSearchIntegration - mine had the indexers > decoupled from the stores, and referred to by name rather than class. > This might be best in the long run, since as it stands (in Martin's > proposal) different instances of the same indexer class would > be created > for each store - which is simpler in the short term, but > might lose some > possibilities for optimisation further down the line. > This absolutely makes sense! As in simple scenarios this is not needed, I suggest to have both possibilities, defining either in store or outside and reference it by name. regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
