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 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. 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. Any thoughts? Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
