Odd API imperfection

[Sanne]

Quite strange, org.hibernate.search.FullTextSharedSessionBuilder wasn't "wired up".

https://hibernate.onjira.com/browse/HSEARCH-1169
https://hibernate.onjira.com/browse/HSEARCH-1170

[emmanuelbernard]

The reason to have FullTextSharedSessionBuilder is so that the session type built and return still remains a FullTextSession. Check in particular FullTextSession openSession(); in FullTextSharedSessionBuilder.

I think it would be a inconsistent if we were returning an plain Hibernate Session not full-text aware from an already FullTextSession. I was just merely applying the same logic we have in FullTextSession: it returns FullTextSession and not Session.

[hferentschik]

I think it would be a inconsistent if we were returning an plain Hibernate Session not full-text aware from an already FullTextSession. I was just merely applying the same logic we have in FullTextSession: it returns FullTextSession and not Session.

Except for opening a session you do something like Search.getFullTextSession(session);

I am not sure whether the consistency argument applied and I am not a fan of FullTextSharedSessionBuilder.

[Sanne]

Using the static helpers from Search.x is rather ugly IMHO. I expect most
users inject the FullTextSession via their framework of choice. I would
consider it more consistent too to keep the full text extensions. It
doesn't cost much maintenance, plus we have all the needed code already.
Since the interface existed, it looks like an oversight that it wasn't
wired yet.
On 24 Aug 2012 17:29, "Hardy Ferentschik" notifications@github.com wrote:

[emmanuelbernard]

I am not sure whether the consistency argument applied and I am not a fan of FullTextSharedSessionBuilder.

From the look of it, you are not a fan of SharedSessionBuilder period. But that's something we inherit from Hibernate ORM.

[hferentschik]

From the look of it, you are not a fan of SharedSessionBuilder period

correct

I am not sure whether the consistency argument applies

And that was just to make a point ;-)

Overall my concern has always been, that we have to many interfaces in this setup/configuration area. I know you keep saying that everything has it purpose, but I am not convinced. For this reason changes in this area a touchy thing for me. I really think we should have a very close look at this area.

[Sanne]

Not merged yet?

I think consistency is a very important point. We do this kind of wrapping and API enrichment by interface extensions all over, so we should do it here too - independently from the fun we can have arguing if it's the right approach generally: even if we would agree that is not the right approach, then we should start designing a completely new approach for fulltext integration. Others did that: started over with a new name and got some interested followers.

People not liking this style that we propose won't be our users anyway: consistency is very important to programmers, as it shows how heated our discussions become on code style for example.

So I think Hibernate Search is committed to a philosophy, it has always been. Even if I would think this API was smelly (which I do not), I think this patch should be part of it. Conceptually, it is part of Hibernate Search. It has always been, it wasn't in the code because we forgot. Our fault.

don't keep me out :)

[hferentschik]

Rebased and applied. I am still not 100% convinced, but it is in the end not a biggie either.

[Sanne]

Rebased and applied. I am still not 100% convinced, but it is in the end not a biggie either.

thanks!