org.hibernate.engine.jdbc.NonContextualLobCreator
by Steve Ebersole
Since master relies on jdk 1.6 (JDBC 4) I am thinking we should go ahead and
make non-contextual LOB creation return concrete implementations as opposed to
jdk proxies. The only real argument I see is *potentially* future proofing
against JDBC 5
Thoughts?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
Re: [hibernate-dev] HV - Follow-Up: meta data API for method constraints
by hibernate＠ferentschik.de
Awesome. I'll look at it asap. I am sure it is ok after all our discussions. Getting ready for a release on Monday. Awesome work guys.
Sent from my HTC
----- Reply message -----
From: "Gunnar Morling" <gunnar.morling(a)googlemail.com>
Date: Sat, Mar 5, 2011 12:39
Subject: HV - Follow-Up: meta data API for method constraints
To: "Emmanuel Bernard" <emmanuel(a)hibernate.org>, "Hardy Ferentschik" <hibernate(a)ferentschik.de>, "Kevin Pollet" <pollet.kevin(a)gmail.com>
Cc: <hibernate-dev(a)lists.jboss.org>
Hi guys,
I just created the pull request for HV-371:
https://github.com/hibernate/hibernate-validator/pull/35
Just one note on MethodDescriptor: getParameterTypes() was not even
necessary, as this information can be retrieved using
getParameterDescriptors().
This all was way more work than I had expected, but after all I think this
looks quite ok. In case you have any ideas for improvement, just let me
know. Otherwise I think we are ready for Beta2.
Gunnar
PS: Emmanuel, thanks for featuring Kevin's and my nomination for the
community awards on in.relation.to. Now we just need some more votes :)
2011/3/1 Gunnar Morling <gunnar.morling(a)googlemail.com>
> Alright, I'll change this then as proposed.
>
> 2011/3/1 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> Looks fine to me. I was concerned about passing Method around as well.
>>
>> On 1 mars 2011, at 00:29, Gunnar Morling wrote:
>>
>> Hi,
>>
>> I pretty much finished the implementation of the meta data API related to
>> method level constraints for Hibernate Validator (see
>> https://github.com/gunnarmorling/hibernate-validator/commits/HV-371). The
>> implementation conforms with what we currently discussed, but right now I'm
>> wondering whether exposing java.lang.reflect.Method on the API is actually a
>> good idea. I see two issues:
>>
>> * Retrieving method objects via the reflection APIs is somewhat nasty, in
>> particular it requires to handle a checked NoSuchMethodException:
>>
>> try {
>> Method bar = Foo.class.getDeclaredMethod( "bar", String.class );
>> }
>> catch(Exception e) {
>> throw new RuntimeException(e);
>> }
>>
>> * The handling in inheritance hierarchies with overridden/implemented
>> methods can be confusing to users not overly familiar with the reflection
>> API. In particular there are different method objects for a base method and
>> its implementation/overriding methods. This can be irritating when invoking
>> MethodDescriptor#getMethod() for instance.
>>
>> Therefore I would be interested in feedback on the following change:
>>
>> public interface TypeDescriptor extends ElementDescriptor {
>>
>> MethodDescriptor getConstraintsForMethod(String name, Class<?>...
>> parameterTypes);
>> //instead of MethodDescriptor getConstraintsForMethod(Method method);
>> ...
>> }
>>
>> public interface MethodDescriptor extends ElementDescriptor {
>>
>> String getName();
>>
>> List<Class<?>> parameterTypes();
>> //instead of Method getMethod()
>> ...
>> }
>>
>> WDYT?
>>
>> Thanks, Gunnar
>>
>>
>>
>
13 years, 1 month
Integrating new transaction work.
by Steve Ebersole
I have run across a few decisions while integrating the new transaction work.
The first 2 are descisions I made while developing the new code that I wanted
to get some feedback on.
-----------------
1) Transaction instances are no longer reusable. The impact here is that code
such as the following would no longer be valid:
Transaction t = session.getTransaction();
t.begin();
...
t.commit();
t.begin();
...
t.commit();
However, this is still valid:
session.getTransaction().begin();
...
session.getTransaction().commit();
session.getTransaction().begin();
...
session.getTransaction().commit();
As is:
Transaction t = session.getTransaction();
t.begin();
...
t.commit();
t = session.getTransaction();
t.begin();
...
t.commit();
Or even:
Transaction t = session.beginTransaction();
...
t.commit();
t = session.beginTransaction();
...
t.commit();
-----------------
2) Subsequent begins() are no longer allowed. This has always been a pet-
peeve of mine that code such as this is perfectly valid:
Transaction t = session.getTransaction();
t.begin();
...
t.begin();
t.begin();
t.begin();
...
t.commit();
What is included in the commit?
-----------------
3) disconnect/reconnect chaining. This is really only important in cases of
user-supplied connections[1] (in fact we should probably disallow disconnect
and reconnect unless that is the case). It is meant to disconnect the session
from the underlying JDBC connection and later reconnect it (generally speaking
the use case here is serialization in say conversations).
Today we allow disconnection of a Sesson that currently has an active
transaction in such a way that the transaction remains valid. So I see 2
potential clarifications to this behavior (in both cases lets assume we
disallow disconnect if the connection is user-supplied):
a) disallow the disconnect if the Session currently has an active transaction
b) implicitly commit any current trasaction on disconnect.
Personally I am not a fan of (b) for the simple fact that I am not sold that
the natural follow up of automatically beginning a transaction on reconnect
makes sense.
(a) would look like:
Session s = sf.openSession(connection);
s.beginTransaction();
..
s.getTransaction().commit(); // generally manual flush mode
connection = s.disconnect();
...
s.reconnect(connection);
s.beginTransaction();
...
s.flush();
s.getTransaction().commit();
Note that in the non-user-supplied case, the disconnect and reconnect are
implicit as a natural part of the transaction lifecycle due to connection
release modes.
-----------------
[1] SessionFactory.openSession(someConnection)
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years, 1 month
HSearch o.h.search.engine
by Emmanuel Bernard
It seems that the engine package content is entirely related to query and should move somewhere under o.h.search.query.
Any opinion or objection? Most are non API non SPI classes anyways.
13 years, 1 month
Re: [hibernate-dev] HSearch o.h.search.engine
by Emmanuel Bernard
Which part specifically?
I can't really finish HSEARCH-687 without it.
On 2 mars 2011, at 23:24, Sanne Grinovero wrote:
> fine for me, but we could postpone such a change?
> I believe both Hardy and me have many pending changes to integrate in
> the same area.
>
> 2011/3/2 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> It seems that the engine package content is entirely related to query and should move somewhere under o.h.search.query.
>> Any opinion or objection? Most are non API non SPI classes anyways.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
13 years, 1 month
Hibernate Search: FieldCache usage for classtype extraction from Documents
by Sanne Grinovero
Hello,
I was playing with a "standard" FieldCache, having as goal to
accelerate the extraction of what we need mostly: classtype and
primary Id.
Focusing on classtype only, it seems that we have to be careful with
FieldCaches:
1 - Strings are extracted as different instances, copying over and
over the same value
2 - The loading via a FieldCache always loads *all* elements from a
given segment, resulting in IndexReader.docMax()
so it's quite possible that this approach takes hostage of a lot of
memory. It's all kept via soft references, so shouldn't really be a
dangerous business, but if these soft references are cleared
frequently that really defeats the purpose, as the FieldCache being
enabled would force extraction again of all values each time they are
needed. They won't just load the values we need over and over, but all
values from the index, including all which are not being matched by
the current query.
So to cope with this, I've now built a custom fieldCache and a
specialized Collector, which extract the data and keep it in memory
not as String but as Class instances, which have the advantage of
pointing to the same instances.
This gets with more reasonable numbers in terms of memory usage, but
now I have tried to get some performance number which justifies the
memory usage:
very bad news, it's around 100X slower when using the cache than
without (considering the warmed up cache only).
profiling, it's all about an innocently looking Map.put() which I'm
now using in the custom collector.
Basically, I'm going to need to change the approach, or kill the
feature. I'm now collecting values into an array and will see how it
goes.
In case someone wants to have a look, there's a working branch here:
https://github.com/Sanne/hibernate-search/tree/HSEARCH-531
and this is the line which is taking now 93% CPU time during a fulltext search:
https://github.com/Sanne/hibernate-search/commit/735c4644834cc516effa33f6...
(Hardy beware of your map usage! this is worse than we expected.. you
definitely have to switch to a per-field collector instance if
possible)
Cheers,
Sanne
13 years, 1 month
Re: [hibernate-dev] hibernate-dev Digest, Vol 56, Issue 20
by Marc Schipperheyn
I have a lot of experience with Bobo Browse. The code is well maintained and
performs well.
I don't have time to download and implement code examples, but if you have
working examples up somewhere, I'd be happy to take a look.
Vriendelijke groet,
Marc
On Mon, Feb 28, 2011 at 6:00 PM, <hibernate-dev-request(a)lists.jboss.org>wrote:
> Send hibernate-dev mailing list submissions to
> hibernate-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> or, via email, send a message with subject or body 'help' to
> hibernate-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> hibernate-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hibernate-dev digest..."
>
>
> Today's Topics:
>
> 1. [HSearch] Faceting feedback (Hardy Ferentschik)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 28 Feb 2011 16:13:43 +0100
> From: "Hardy Ferentschik" <hibernate(a)ferentschik.de>
> Subject: [hibernate-dev] [HSearch] Faceting feedback
> To: "hibernate-dev(a)lists.jboss.org" <hibernate-dev(a)lists.jboss.org>
> Message-ID: <op.vrmck5ewqxbac6(a)sarmakand.lan>
> Content-Type: text/plain; charset=iso-8859-15; format=flowed;
> delsp=yes
>
>
> Hi,
>
> I thought it would be great to get some feedback on my faceting work.
> You can see the latest on my Search fork -
> https://github.com/hferentschik/hibernate-search/commits/HSEARCH-667
>
> Technically I decided to use a simple custom Collector. I abandoned the
> idea for using bobo browse, since it did
> not really seem to fit our architecture and I am not sure how well
> maintained the code is.
> Within the custom Collector I am using Lucene's FieldCache to cache and
> collect the count values during facting
> (as a reminder, faceting for example means that I am searching for all
> cars or a certain make, but then also want
> to group the matching cars into their cubic capacity. See also -
> http://en.wikipedia.org/wiki/Faceted_search)
> Using the FieldCache is quite memory costly, but there are other ways to
> implement the faceting itself.
>
> At the moment I am mostly interested in the feedback around the public
> API. The public classes can be found in
> the package org.hibernate.search.query.facet -
>
> https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
>
> The idea is to write a fulltext query as usual and then add/enable a facet:
>
> FacetRequest request = new SimpleFacetRequest( indexFieldName,
> FacetSortOrder.COUNT_DESC, false );
> TermQuery term = new TermQuery( new Term( "make", "honda" ) );
> FullTextQuery query = fullTextSession.createFullTextQuery( term, Car.class
> );
> query.enableQueryFacet( "foo", request );
>
> Then you run the query. This will enable the facet collector and after the
> query executed you get access to a map
> which maps FacetResults to the facet name. Each FacetResult contains a
> list of Facets which contain the actually
> field values and counts:
>
> Map<String, FacetResult> results = query.getFacetResults();
> FacetResult facetResult = results.get( "foo" );
> List<Facet> facetList = facetResult.getFacets();
> assertEquals( "Wrong facet count for facet ", 100, facetList.get( 0
> ).getCount() );
>
> More actual tests can be found here -
>
> https://github.com/hferentschik/hibernate-search/tree/3a9877e2bbc47a8bd6e...
>
> At the moment you are able to facet on simple (string) based values or on
> number ranges (eg price ranges 0 - 100, ...). For that I have created
> subclasses of
> FacetRequest - SimpleFacetRequest and RangeFacetRequest (a
> DateRangeFacetRequest might be interesting as well)
>
> Some concrete questions:
> * Atm, I am only exposing a programmatic API for creating FacetRequests. I
> guess we want to have annotations for this as well, right?
> Would we keep the programmatic configuration as a public API?
> * I made the FacetRequest classes immutable atm, but this way I have a
> multitude of constructors catering for a whole range of parameters
> (sort order, include zero counts, ...). Any opinions around immutable
> objects vs objects with setters for configuring options after creation.
>
> If course I am interested in any other feedback as well.
>
> --Hardy
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> End of hibernate-dev Digest, Vol 56, Issue 20
> *********************************************
>
13 years, 1 month
