[hibernate-dev] Hibernate Search road map

[Emmanuel Bernard]

Sorry for the delay Sanne and thanks for the constant work. Feel free  
to bug me I will say no if I can't.

On  Feb 25, 2009, at 06:19, Sanne Grinovero wrote:

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

I added some notes in JIRA. Feel free to tell me if you update this  
jira (I might miss it).

>
> It would be nice if the solution could be reused also by other
> listeners (a topic for JPA2 spec?)

forget it.

>
>
> HSEARCH-178 is very annoying and I see it hitting many people;
> probably the new HSEARCH-342
> is another duplicate.

what makes you think it's a 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.

ping me tomorrow or this week end, or detail that point, I don't  
understand what you are proposing.
Yes it should work on any backend.

>
>
> * 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 ;-)

Is it because it's "hard to do" or is a conceptual problem.
I am happy to not support that for the first release.

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

looks good but try and make it a fluent API (ie method chaining  
returning si and remove set in set*.
Is there any non optional setter?

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

Couldn't you use the same thing that we did for FullTextQuery with  
setCriteria?
I am happy to delay that for later. Especially since JPA2 is coming  
with a criteria API.

>
>
> 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 <emmanuel at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>