[hibernate-dev] Search: how to define hints for batch indexing

[Sanne Grinovero]

Hi everyone,

I am working on batch indexing for Hibernate Search, I would like to define
a new annotation
to set the needed "hints" for the process "@BatchIndexingHints"; one of the
hint parameters is "which HQL query should I use?"
The query is optional and I can fallback to a simple scrolling criteria,
also this query should
not affect the functionality, only a performance hint to define join fetch
collections needed for indexing.

The options we found (speaking with Emmanuel) are 4:

1)don't ask for a query but for the name of a named query.
I don't like this one as the definition of a named query is too flexible,
e.g. I know for sure the
"readonly=true" is preferable for my purpose. Also this query is going to be
created only once per
thread during an indexing process, so I don't foresee a considerable
performance boost.
Additionally the name of the NamedQuery would be redundant as I would be the
only user (probably).

2)define the HQL to load all entities in @BatchIndexingHints.

3)Let the user only define a list of Strings, naming the properties to be
eagerly loaded;
I would add these using .setFetchMode("prop1", FetchMode.EAGER) on the base
Criteria.
This would be nice as we could be sure the users can't add some restriction
or load
the wrong entity, making it more safe.
But I wonder if we are loosing too much flexibility in this case.

4)don't tell anything at class level put add a boolean to desired fields,
something like
@Field(eagerInBatch=true) or @Field(InBatch=FetchType.EAGER)
(adding a property to existing annotation)

Besides the eagerly loading query the other parameters are 3 ints needed to
set the size
of 3 different ThreadPools which do the job at different stages; they are
here to provide
a nice per-entity default, but if I move them to a configuration property
and we
select option 4) I could avoid the new annotation.

some comments?

Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Work on HHH-3110

[Les Hazlewood]

Hey guys,

I finally was able to attack this today and created an issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3358

The patch was created based on an SVN checkout of trunk and attached
to the issue.  Comments about the change and exactly what I did are
detailed as well.

The best thing about the fix is that I realized I didn't need to add
any parent abstract classes or even subclasses.  I was even able to
consolidate a common JNDI lookup that was spread out (perhaps
unnecessarily) across two classes into one class in one method.

The change was pretty clean and only touched two files, but still
retains backward compatibility.

Please let me know what you think!

Thanks,

Les

On Fri, Jun 20, 2008 at 9:52 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> Hi Steve!
>
> Great to hear from you again :)
>
>> Not sure why you find it so interesting considering that that JTA spec
>> itself *requires* binding into JNDI :)  This is true both in the older
>> 1.0.1B as well as the latest 1.1 specs.  Thus I do not believe
>> that org.hibernate.transaction.JTATransaction is the correct place to
>> be adding support for not acquiring these resources from JNDI.
>
> My frustration lies in the JTA spec itself, requiring JNDI due to
> remnants from the EJB 2.1 era.  Which is why I consider my approach to
> be a feature request as opposed to a bug - its a 'nice to have' when
> using a JTA TM that doesn't require JNDI.
>
> And I agree that JTATransaction _should_ be using the JNDI lookup - my
> intention was never to change that, ensuring 100% backwards
> compatibility.  My intention was that the JTATransaction was a minimal
> subclass of a parent abstract class.  That abstract class would
> delegate to children classes how do do the lookup, and in the
> JTATransaction case, it would do it from JNDI, just as things occur
> today.
>
>> However, I have no issue with adding support for these psuedo-JTA TMs.
>> Its just a matter of semantics and being consistent with terminology.
>> So, the basic thing we are trying to describe is support for interacting
>> with "distributed transaction" systems.  So, I'd prefer that the base
>> class in question here be called DistributedTransaction, of which
>> JTATransaction would be a subclass with the same behavior as it has
>> today (some delegated to its new super).  And from there we can begin to
>> build the support for Atomikos and the other TP services not conforming
>> to the JNDI aspect of the JTA spec.
>
> Perfect, this is exactly my thinking as well.  And I much prefer your
> superclass name ;)   I'll post to this list again when I have my patch
> attached to the issue so you guys can see the end result.
>
> Thanks again,
>
> Les
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev