Re: [hibernate-dev] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?
On 21 Jan 2013, at 12:17 AM, Guillaume Smet wrote: > Hi Sanne, > > On Thu, Jun 20, 2013 at 6:45 PM, Sanne Grinovero wrote: >> Great, so maybe we should just do that. > > Yep, looks like a good idea and would be far cleaner. +1 once we use Jandex we can fore sure do that. On the other hand, you are saying that you are using Hibernate Search which means that you have at last one @Indexed class. Why not add the definitions there? Would that not be a logical place anyways? Another thought, I wonder whether you could use the programmatic API to just define the analyser definition on a non indexed entity? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] DocumentBuilder refactoring in Hibernate Search: how to deal (internally) with metadata
> I'm sorry I now realize I made it hard to understand as I didn't
> actually explain how I mean this to be recursive.
>
> First, note that another frequently requested feature is to be able to
> add some fields to a Document *in addition* to what we would normally
> do.
> Today this flexibility is granted by defining a class level bridge,
> but by doing so this disables processing of @Field annotations, so
> people can't decorate but have to hardcode the full transformation in
> their bridge.
How does a class bridge "disables processing of @Field annotations".
> To solve that - and the design mentioned above - I was thinking of
> compositing bridges recursively to match the metadata.
"compositing bridges recursively to match the metadata"? Even by
replacing compositing with composing I am not quite sure what you are after.
> To express that in pseudo-functional code, an entity:
>
> @ClassBridge(impl=CustomAnimals.class)
> @Indexed
> class Animal {
> @Id long id;
> @IndexedEmbedded Color skinColor;
> @Field name;
> }
>
> would generate a reusable transformation function which gets
> associated to the Animal.class
>
> class ObjectToDocument {
> Document transform(Entity e);
> }
> [not exactly like that, bear with me a moment]
and how would the user hook in there?
IIRC some users just wanted the ability to get hold of the Lucene document
before it gets indexed.
I think we can make this happen without changing anything around the bridges
etc.
We just need to hook somewhere into DocumentBuilderIndexedEntity#getDocument
> I guess by now you start seeing the problem of defining the exact
> signature of such composite transformation blocks:
> I mentioned Visitor in my first email as I think it could help, but it
> doesn't have to be strictly a Visitor.
Sorry, I still don't fully understand. That's not to say that I am against a
new way of getting from entity
to document, but I don't see what of the things you mentioned is not possible
today.
> The problem is that we will want to navigate the internal metadata for
> different purposes, as I had outlined in the next paragraph; generally
> a Visitor allows to decouple the metadata graph from the purpose,
> while also preserving a good level of typesafety and performance:
> let's not forget this is one of the hottest areas of the Search
> codebase (CPU wise), and at the same time the place where we trigger
> the more important optimisations, like opportunities to skip network
> operations or disk IO.
Fair enough. However, imo the visitor pattern adds also quite some complexity
and becomes useful where you have to an object structure with many different
types. In our case the metadata for a single indexed type is quite "simple".
>>> - We need a reliable way to track which field names are created, and
>>> from which bridge they are originating (including custom bridges:
>>> HSEARCH-904)
I am working on this. As mentioned before, my idea for this was to add another
interface a bridge can implement. This interface reports the required meta
information
(the fields which are getting added plus maybe their Lucene index settings).
For the
built-in bridges we implement this interface. Implementors of custom bridges
will need to
implement this interface.
>>> - If we could know in advance which properties of the entities need
>>> to be initialized for a complete Document to be created we could
>>> generate more efficient queries at entity initialization time, or at
>>> MassIndexing select time. I think users really would expect such a
>>> clever integration with ORM (HSEARCH-1235)
But this is all a question on which metadata we collect not on how we process
it.
> Seems in the list above I forgot my favorite one: dump the metadata as
> simple text on bootup; this should greatly simplify query writing, and
> doesn't need to open the index with Luke to figure out the field names
> / options.
+1 I like this idea. Maybe instead of dumping the internal metadata we should
dump
the public metadata information once I am finished with HSEARCH-436
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?
I've actually found a flaw in my suggestion: a scan of all user provided classes might not be desirable. For one, someone might have some unintended dependencies which happen to include such an @AnalyzerDef, which could conflict with some definition name being used elsewhere and this is not always easy to control. Ok that might be far fetched, but there is a stronger use case: some applications use multiple entity sets, mixing them in various Persistence Units. Those users typically rely on the configuration capabilities of JPA / Hibernate to disable annotation scanning and list entities explicitly, jars explicitly, packages, etc.. When relying on @MappedSuperClass or other *known* entities, we inherently take advantage of these isolation features to nicely build just what is expected and no more; if we where to scan all user classpath without these restrictions, the user wouldn't have an option to specify some kind of filtering when needed. Assuming we don't want to be too coupled to ORM - Search integrates with more - then we need an alternative filtering option, and we would need to reimplement such logic. Guillaume, could you clarify the use case once more? I am assuming it was all about a cleaner code organization; in that case wouldn't it be enough to specify a single class to be scanned for the global analyzer definitions? Sanne On 21 June 2013 10:33, Hardy Ferentschik wrote: > > On 21 Jan 2013, at 12:17 AM, Guillaume Smet wrote: > >> Hi Sanne, >> >> On Thu, Jun 20, 2013 at 6:45 PM, Sanne Grinovero wrote: >>> Great, so maybe we should just do that. >> >> Yep, looks like a good idea and would be far cleaner. > > +1 once we use Jandex we can fore sure do that. > > On the other hand, you are saying that you are using Hibernate Search which > means that > you have at last one @Indexed class. Why not add the definitions there? Would > that not be a > logical place anyways? > > Another thought, I wonder whether you could use the programmatic API to just > define the analyser > definition on a non indexed entity? > > --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?
On Fri, Jun 21, 2013 at 12:17 PM, Sanne Grinovero wrote: > Guillaume, could you clarify the use case once more? I am assuming it > was all about a cleaner code organization; in that case wouldn't it be > enough to specify a single class to be scanned for the global analyzer > definitions? You assume correctly. Our core library doesn't contain any entity and I want to declare the @AnalyzerDefs in this library to be able to use them everywhere. Currently, we created a dummy entity to be able to do so. The fact is that it creates a table in the database which is not very compelling. I agree that a @MappedSuperClass would be an hack too, but it's less ugly than an @Entity. So scanning a single class would be enough, at least for our needs, as we centralize all our global @AnalyzerDefs here. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?
On Fri, Jun 21, 2013 at 2:35 PM, Hardy Ferentschik wrote: > Again, I still don't see the connection between @Entity and @AnalyzerDefs. > How does you library look like and what do you want to provide. Can you > provide > an example. Does your library contain an indexed type? Are you using Search in > conjunction with ORM? Yes, I do use ORM. Well, the only connection is that if I add an @Entity annotation, it works. If I don't, it doesn't. But I agree with you that I would prefer no connection at all :). >> Currently, we created a dummy entity to be able to do so. The fact is >> that it creates a table in the database which is not very compelling. > > Create a dummy class with @Indexed, or is that not working? No, it doesn't. My point is that @AnalyzerDefs discovery is tied up to having an @Entity annotation on the class. At least, when you have ORM in the way. I tested with: - @Indexed -> doesn't work - @MappedSuperClass -> doesn't work - @Entity without @Indexed -> works like a charm I haven't looked at the code yet, I asked the question before digging too much into it. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Search] Why is global @AnalyzerDefs scanning limited to @Entity?
On 21 Jan 2013, at 2:26 PM, Guillaume Smet wrote: > On Fri, Jun 21, 2013 at 12:17 PM, Sanne Grinovero wrote: >> Guillaume, could you clarify the use case once more? I am assuming it >> was all about a cleaner code organization; in that case wouldn't it be >> enough to specify a single class to be scanned for the global analyzer >> definitions? > > You assume correctly. > > Our core library doesn't contain any entity and I want to declare the > @AnalyzerDefs in this library to be able to use them everywhere. Again, I still don't see the connection between @Entity and @AnalyzerDefs. How does you library look like and what do you want to provide. Can you provide an example. Does your library contain an indexed type? Are you using Search in conjunction with ORM? > Currently, we created a dummy entity to be able to do so. The fact is > that it creates a table in the database which is not very compelling. Create a dummy class with @Indexed, or is that not working? --Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate in the JBoss Community Recognition Awards
The Hibernate community has multiple contributors nominated for the 2013 JBoss Community Recognition Awards. Please take a moment and vote! https://www.jboss.org/jbcra/vote.html From the nomination introductions, in no particular order: Guillaume Smet - Guillaume Smet has been thoroughly testing Hibernate Search, and providing many critical fixes. His contributions have been priceless and he also regularly contributes to the mailing list with great advice. Not least, he motivates us all to put the quality bar higher at every release. Łukasz Antoniak - Łukasz is always willing to dig in and tackle difficult issues spanning a *wide* breadth of topics -- especially ones outside the scope of his typical expertise. His help in resolving many issues in the Hibernate database testing matrix really illustrates how reliably amazingly his contributions have been. These were mostly databases where we could not offer him the greatest tooling (often not even database access to databases being tested). Those were contributions that directly affected Hibernate and EAP timelines in very positive ways. And all of that in addition to maintaining Envers... Guillaume Scheibel looks like a full time Hibernate team member. He has been leading the development for the MongoDB GridDialect for Hibernate OGM, developed most of it himself, and participates in design decisions. The need for Hibernate OGM to have a MongoDB/Infinispan integration to complete query support was reason enough for him to implement one and contribute it to Infinispan. Not least, he presented the project at JUG events! Nicolas Helleringer - Nicolas proposed a great new feature to the Hibernate Search project: spatial queries and proximity filtering. He lead the design of it in the most collaborative way with the team, donated his expertise in spatial coordinates handling, spent months to implement it and polish it considering feedback from the whole community, and a year later is still actively helping new users with it, improving documentation and taking ownership of bug reports. Tim Ward - Tim's expertise, help, advice and support were instrumental in getting OSGi support into Hibernate. As an Apache Aries PMC member and Enterprise OSGi advocate, Tim has a wealth of knowledge; but his patience and knack for doing a *great* job at explaining the concepts were what made him truly amazing to work with. Without Tim's help OSGi support in Hibernate would still be a talking point rather than an implemented reality. Brett Meyer Red Hat Software Engineer, Hibernate ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
