Hi, I am happy with the "new features" in the roadmap, but still a bit worried about some open issues: HSEARCH-314 is quite annoying and I've run out of ideas to propose; any direction from someone? It would be nice if the solution could be reused also by other listeners (a topic for JPA2 spec?)
HSEARCH-178 is very annoying and I see it hitting many people; probably the new HSEARCH-342 is another duplicate. ** About mass indexing ** I've lots of implementations in house, mostly experiments, many working well, but I can't really satisfy all requirements. Could we define exactly which requirements the first public version should be able to cover? In particular: * if it should work on any backend (using the pluggable backend api) or generate a local file index, reusing some backend code but using a direct reference instead of going through the interface and skipping the "Work" value objects. * Composite pk: to have a consistent view of DB even in multithreaded indexing on an online DB the best solution I've found is to have a single-threaded pk producer (load all pk's from db) which hands the pks to multiple object loaders, and at the same time keep track of other enqueued events (to process them in order at the end of indexing). This works ok if the pks are simple value objects, not graphs of composite objects ;-) * The API: my first ideas were about defining the indexing finetuning parameters (loading queries, caching, number of threads, queue sizes...) on an annotation on top of the class. Emmanuel didn't like it, and I don't like it either anymore: still some API should be defined; to be flexible enough I was thinking in something like this: SearchIndexer si = (SearchFactory instance).createIndexer(); // to rebuild all indexes, or sf.createIndexer( Class... types) si.setIndexWritingThreads( 2 ); // optional, default to 1 si.setLoadingThreads( 8 ); // optional, default to 1 si.setCacheMode( CacheMode... ); // optional, default to IGNORE in some acses useful to not ignore. si.setOptimizeAtEnd( false ) // optional, default to true si.setPurgeAllAtStart( false ) // optional, default to true (does purge and optimize) si. --add more options in future as needed -- si.start(); // can call it only once si.waitForFinish( timeout ) // optional Additionally, I would like to add some way that the user could define an optimal loading query, but this gets messy to check, especially in cases I am indexing different types having some inheritance relationship. We could leave this for future, or only add something like a Criteria.setFetchMode scoped per type, which is what I ususally need: si.setFetchMode(Class scopeHintToType, String relationName, FetchMode). The time to implement really depends on the amount of integration desired with the current backends; as to make a trivial local indexer I've lots of code to paste as soon as the API is set. I've some optimizations for the future, but would like to provide at least the basics soon. regards, Sanne 2009/2/20 Emmanuel Bernard <emman...@hibernate.org>: > I updated the road map > http://www.hibernate.org/357.html#A12 > > Mass indexing > Dictionary / spellchecker support > Work on easier query building > More like this? > Built-in clustering with JBoss cache > Statistics > custom LockFactory > > feel free to propose other new features. > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
