Hibernate assumes arguments in HQL query where there are none
by Marcel Stör
I tried debugging the warning "Function template anticipated 3
arguments, but 2 arguments encountered" in TemplateRenderer. However, I
still don't understand what's actually going on...
The following uses an HQL query because there seems to be no
string-to-int conversion in JPQL (resorting to HQL cast):
public Set<Long> findImageVariantIdsWithOutOfBoundsDimension() {
final StringBuilder queryBuilder = new StringBuilder();
queryBuilder.append("select id from ImageVariant where ");
// imageVariantType is something like R_110X75 with 110 being max x.
// cast(substring( extracts 110.
queryBuilder.append("dimensionX > cast(substring(imageVariantType, 3,
locate('X', imageVariantType) - 3), int) ");
queryBuilder.append("or ");
// imageVariantType is something like R_110X75 with 75 being max y.
// cast(substring( extracts 75.
queryBuilder.append("dimensionY > cast(substring(imageVariantType,
locate('X', imageVariantType) + 1), int)");
final Query query =
getEntityManager().createQuery(queryBuilder.toString());
@SuppressWarnings("unchecked")
final Set<Long> result = new HashSet<Long>(query.getResultList());
return result;
}
I checked TemplateRenderer's internal argument list which contains ['X',
imagevaria0_.imagevarianttype]. I'm totally puzzled.
Cheers,
Marcel
--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
14 years, 3 months
metamodel thoughts
by Steve Ebersole
Wanted to get my thoughts on the current state of the metamodel down so
we could all discuss.
First to define some vocab for discussing. I say that the old code
(Configuration, HBMBinder/AnnotationBinder, mapping package) used a
"push" model. The binders interpreted the various user supplied values
and made decisions *pushing* the results of those decisions to the
mapping classes. The new code attempts a "pull" approach. The user
values are interpreted into BindingState and RelationalState objects
which get passed in to the Binding objects which *pull* the data from
the states.
At the most basic of descriptions, what is it we are trying to
accomplish here? Well we have some mapping information supplied by the
user in a number of forms (hbm, annotations, etc) and need to correctly
build/populate a binding model based on the values and interpretations
of those values.
In designing I always go back to the question of "how would I accomplish
this task by hand". Here, the first thing I see is that we have user
values in multiple formats. So the very first thing I would do,
ideally, is to some how normalize values from those different "sources".
I would then take those normalized values and then populate the
binding model.
So here is what I suggest:
1) What we currently call "state" objects would serve the role of this
normalization. We would have specific things to normalize hbm,
annotations, etc. It could even be just different implementations of
the same normalized interface which are constructed with whatever they
need to answer the contract queries.
2) These normalized value objects are then passed into THE binder which
uses the information there to build and populate the bindings. 2 things
to note here. First I said THE binder. The idea is that there is just
one for both annotations and hbm as the differences were removed during
normalization. Second this part is a push approach. Specifically that
means the bindings and models are mutable.
In my mind this sits between push and pull (or does each)
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 3 months
intermittent NPE during an AS7 testsuite run (with Hibernate 4.0.0.Beta1)
by Scott Marlow
I'm not sure if we will see this NPE again but found the location
interesting. I wanted to report the failure in case it happens again in
the future or anyone else is interested in playing detective for
mysteries like this. ;)
The exception call stack is here http://pastie.org/2104060
It looks to me like AbstractServiceRegistryImpl.serviceBindingMap is
null for some reason. It makes me wonder if
AbstractServiceRegistryImpl.destroy() was called prematurely for some
reason (for some unexpected reason).
I wanted to mention the NPE here in case it happens again, so we can see
what is in common with this one. Next time, we will have to capture the
AS server.log output which might have additional clues but didn't this time.
Scott
14 years, 3 months
Transform theta style join to inner join
by Emanuele.Gesuato＠finantix.com
Hi there,
we are using hibernate3 and we would like to change one of the behaviour
of hibernate in a way to eliminate theta style join in favour of an inner
or left join.
In some cases theta style join on oracle causes a bug because oracle
doesn't support "oracle style" FROM caluse ("from a,d") with ANSI ("inner
join ...").
("http://forums.oracle.com/forums/thread.jspa?threadID=412019")
So, one of the way could be to remove the theta style join in favour of an
inner join in the sql that should be equivalent.
Not sure if it's the best way to accomplish this task. Looking in the
source code i've tried to modify DotNode class in a way to avoid implicit
joins. But running
testcases i discovered i added several regression :(. This is because i'm
here to ask to the hibernate guru what is the best way (if there is one)
to accomplish this task.
Thanks for the patience,
Emanuele Gesuato
14 years, 3 months
EntityBindingState
by Steve Ebersole
In looking at
http://opensource.atlassian.com/projects/hibernate/browse/HHH-6338 I
really started digging into this notion of "binding state" and
specifically EntityBindingState.
I ran into a question. I don't quite follow reasons for some of the
details here. For example, I do not get why we:
1) instantiate an EntityBinding
2) instantiate an Entity, and pass it into the EntityBinding
3) instantiate a EntityBindingState and pass it into the EntityBinding.
Given what I understand the point of the "binding state" to be, the step
I specifically do not get is (2). Why not just make the information
needed to create the Entity instance (name, supertype) part of the
EntityBindingState contract and:
1) instantiate an EntityBinding2)
2) instantiate a EntityBindingState and pass it into the EntityBinding.
Then the EntityBinding can create the Entity as it needs based on
EntityBindingState.
I did not want to just start making changes here without understanding
the reasoning for doing it the way it is.
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
14 years, 3 months
[HSEARCH] package split in API/SPI/private aka HSEARCH-746
by Emmanuel Bernard
I've started the work to split classes between API, SPI and private classes.
Some areas went very well, some are more problematic but that was to be expected. Anyways it did generate a couple of questions from philosophical to concrete. Please try and chime in.
1.
API vs SPI: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-746
I have a question on API vs SPI.
The Hibernate Core team uses the following rule:
- any "public" API not directly called by the user application is a SPI (for example a Bridge would be SPI and I imagine BootStrategy would be too etc).
We could however sue a different rule:
- any API targeted at frameworks integrating with Hibernate Search are SPIs For example SearchConfiguration and SearchFactoryIntegrator would be SPIs but Bridge classes and BoostStrategy would not
I'm tempted by the second definition as it separate user focused classes from integration / framework focused classes. Of course nothing is in back and white and some classes can be hard to categorize.
An aternative approach is to mix the two definitions:
- any "public" API not directly called by the user application is a SPI (for example a Bridge would be SPI and I imagine BootStrategy would be too etc).
- any API targeted at frameworks integrating with Hibernate Search are SPIs For example SearchConfiguration and SearchFactoryIntegrator would be SPIs
But then we lose the distinction between framework APIs and user APIs.
What do you think?
2. Specific issues:
o org.hibernate.search.batchindexing.impl.Executors is used by MutablefactoryTest
should we keep executors as private or should we consider it an actual API or SPI?
o Should built-in types be public APIs/SPIs?
I was tempted to put some if not all as private classes but there are use cases where these classes are used by actual users:
- the programmatic API (ProgrammaticSearchMappingFactory uses them)
- provided id settings
Should we consider some / all as public classes? For example what about ClassBridge?
o Is NumericFieldUtils a public class? It is used by NumericFieldTest, ProjectionQueryTest but it seems a user should not use this helper class
o SearchConfiguration is very likely an SPI which means we will need to break Infinispan's query module, is that OK?
o Programmatic API
*Mapping objects are messed up with *Descriptor objects
It seems to be that *Descriptors should be private while *Mapping should be API, do you think it's worth working on this? The programmatic mapping si still considered experimental so we have some time I guess.
o SearchFactoryIntegrator vs SearchFactoryImplementor
In my mind, I introduced SearchFactoryIntegrator to separate private SearchFactory usage from frameworks usage.
Does the Infinispan Query module depends on SearchFactoryImplementor only? Or is it depending on SearchFactoryImplementor?
That's all for now but more will come :)
Emmanuel
14 years, 3 months
Multi-tenant roadmap
by Peter Yuill
I tested the recent multi-tenant code in hibernate 4 and it works well
in the mode of the test case (manual session creation). Thanks guys,
great work.
My question is about support for what I see as the more normal usage of
SessionFactory getCurrentSession(). Looking at the current code I cannot
see a way to tell any of the SessionContext implementations to use a
specific tenant id when building the session in getCurrentSession(). Is
this something that is being looked at, or are we stuck with manual
session creation to use the multi-tenant feature?
Regards,
Peter
14 years, 3 months
