Secondary table support 5.0
by Steve Ebersole
Secondary table support is pretty much done on the metamodel branch.
One thing we should discuss is support for using property-ref in
conjunction with <key/> there in hbm.xml.
Hibernate has never supported this. But I wanted to look at adding
support for it in 5.0 with these metamodel changes. What I found is
that we *could* support it, but that would mean a few changes and
"limitations".
First, the limitations come down to:
1) property-refs would have to be limited to naming properties whose
columns are part of the primary table. I don't think this is a huge
deal in practice.
2) hbm.xml does not support "nested" secondary tables. Basically it is
assumed that all foreign keys across all secondary tables reference back
to the primary table.
We could somewhat alleviate these limitations by allowing the nesting of
joins. This starts to get complicated to support in-and-of-itself
though. But in this approach, property-refs could name properties
defined as part of any <join/> mappings "above" the one being defined or
the primary table.
The major change this requires in processing comes in Binder.
Currently, when processing an entity, we:
1) bind the primary table,
2) bind its identifier,
3) bind its (if any) secondary tables,
4) bind attributes.
Essentially we follow the JPA model here where the "column sources" name
the table to which they belong (and adapt the hbm.xml model to that
case). However, to support hbm.xml property-refs at all we will need to
change that process. In the approach of not allowing nested secondary
tables, the process would become:
1) bind the primary table
2) bind its identifier
3) *** bind any attributes mapped to the primary table ***,
4) bind its (if any) secondary tables,
5) bind attributes coming from secondary tables
And in terms of allowing the nesting of secondary tables, the process
then needs to become essentially the same as above, but we would need to
process attributes from each secondary table as we process the secondary
table. Interestingly, these approaches more naturally follow the
hbm.xml model.
I guess the first thing to discuss is whether we want to add support for
<key property-ref/> in regards to <join/> for hbm.xml. We kind of want
to steer people to use annotations anyway, so maybe we just decide this
is not worthwhile. WDYT?
--
steve(a)hibernate.org
http://hibernate.org
14 years
Natural IDs and HHH-7241
by Donnchadh Ó Donnabháin
Hi everyone,
Would it be possible to have HHH-7241 looked at for Hibernate ORM 4.1.3 ?
https://hibernate.onjira.com/browse/HHH-7241
For us at least, it blocks us from using natural ids with 4.1.2, but maybe
someone can suggest a workaround if it can't be fixed for 4.1.3.
Thanks,
Donnchadh
14 years
OGM / MongoDB not having failing tests
by Sanne Grinovero
Hi all,
the mongodb branch is not having failing tests any more. It's not
"done" as there are some tasks open and some tests are disabled, still
it's starting to look good.
What about merging the branch in master already?
So we could simplify the development process. The biggest problem I
see is that CI servers don't ave a MongoDB instance running, but for
now we could disable the module from CI until we're actively all
working on it and rely on peer review - as we already do. We could
look into MongoDB instances for CI in parallel, for example as in
Strong's email about travis-ci, cloudbees, or something else.
Sanne
14 years
public (and free) CI service
by Strong Liu
http://travis-ci.org/
I played this in this weekend, and it looks very interesting, and I think maybe we can use this as a smoke test environment.
pros:
1. integrated with github, very simple to set up, the build is triggered by every commit, so it is more like a CI than what we have atm.
2. DB support ( mysql / postgresql / mongo, for OGM )
3. public accessible
4. status image (http://about.travis-ci.org/docs/user/status-images/)
5. matrix support
( it seems have some bugs with this, I tried to set up H2 / MySQL / PostgreSQL matrix for hibernate-orm, but the build finishes successfully, which it should not :)
cons:
1. not stable ( alpha stage )
2. limited configuration ( linux, jdk6 only)
3. junit report not available ( no way to check the failing test stacktrace / report )
if you're interested in this, you can take a look of my set up
http://travis-ci.org/#!/stliu/hibernate-orm
https://github.com/stliu/hibernate-orm/blob/master/.travis.yml
http://travis-ci.org/#!/stliu/hibernate-validator
https://github.com/stliu/hibernate-validator/tree/travis
https://github.com/stliu/hibernate-validator/blob/travis/.travis.yml
the ".travis.yml" is the key.
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
14 years
[HV] Design philosophy
by Emmanuel Bernard
Hi all,
Hardy, Gunnar and I started a discussion that is worth more Eyeballs.
It started after the addition of a `regexp` attribute on @Email to be able to restrict the shape of the email via an extra regexp.
Here is the exchange
> Emmanuel:
> I don't understand. Is this feature different than
>
> @Email @Pattern("regexp")
>
> If that's different I have not found how. If it's not I don't see the point in adding complexity to @Email.
> Hardy:
> The difference is that you only have a single annotation. Internally you are using composing constraints (so not really adding much complexity)
> and report as single violation (which is probably where the advantage lies).
>
> It is probably a matter of taste whether you prefer a single @email annotation or @email and @pattern.
> Emmanuel:
> Also it makes for much less readable code which is something we have constantly discouraged.
>
> What reads better @Email(regexp="^((?!\\.org).)*$") or @SomeEmail(excludeTld="org"). Granted, one need to write
> an custom annotation but readability is much different. I leave it as an exercise to write the same samples if 5 TLDs
> need to be excluded :)
> Hardy:
> @email(regexp="^((?!\.org).)*$")
> You must admit, this is a little bit of a special case. I stumbled across this when looking for negating regexp.
>
> Granted, one need to write an custom annotation but readability is much different.
> in this particular case you might be better off w/ a custom constraint. A more common use case would be to restrict to your
> own subdomain
> Gunnar:
> I think we're basically offering users several options/styles here from which they may chose the one they like best.
> I see use cases where a custom constraint isn't worth the efforts and having the additional pattern restriction within the
> @Email constraint might be preferable over expressing it via a separate @Pattern constraint.
>
> It's also a good thing IMO to be consistent with @URL where we have a regexp() attribute as well (see HV-406).
To reply to this thread and in particular Gunnar, let me expand a bit. Hibernate Validator and to a certain extend other Hibernate projects
have been designed to improve developer productivity not improve choice of style. Choice of style is an important reason why the Java
web stack is so complex to build an application. I don't want to be responsible for adding garbage.
When adding a feature, we have always implicitly asked ourselves this pool of questions:
1. Does it feel like the right way of doing things?
If it's not, we have been prone to wait till we mature on the idea. Take collection element constraints as a good example. We know the right way but
it's not available to us yet
2. Can I do it with an existing construct with similar or less complexity?
3. Is this feature wrong? eg validating unicity with a database query is wrong.
4. Is this a popular request?
5. Is this feature useful in the general scheme? "What's your use case?" mantra.
6. Is it the most readable approach?
7. Is the feature designed consistently with the rest of the library
Keeping the library useful and simple is a constant battle against people wanting to throw new features at it but resisting to the dark side is
important. More than that, I think that's our job to be this gate keeper and we deserve to be shot in the knee and kicked while on the ground.
We are here to make the world a better place, not give food to guideline writers.
If we go back to our example, @Email(regexp=""^((?!\\.org).)*$") is not really 5 nor even 2 times better than @Email @Pattern((regexp=""^((?!\\.org).)*$")
And frankly, regexp is about the less readable construct in the history of programming languages. I am not against some functional flags to
restrict the domain, ensure that it's an email address reachable from the internet etc etc as this can be made very readable and clearly
adds over a mix of @Email + @Pattern. And I also dislike @URL.regexp for the same reasons.
14 years
multi-tenancy in Hibernate and JPA 2.1
by Steve Ebersole
The scope of multi-tenancy in JPA 2.1 is pretty much set it seems, its
just details at this point. And that scope is decidedly different from
what I did for Hibernate. What we have in Hibernate is actually more
encompassing.
The terms being used to describe the differences are PaaS versus SaaS.
What we have in Hibernate falls into what the spec committee is calling
the SaaS category, essentially the ability to run one instance of the
application (and therefore one instance of Hibernate) simultaneously
handling multiple tenant requests. This is stated to be outside the
scope of multi-tenancy for JPA 2.1. Instead JPA 2.1 will support what
the committee is calling PaaS category, essentially multiple instances
of the application (and therefore multiple instances of Hibernate) would
be needed to handle multiple client requests.
Essentially, you could largely achieve what is planned for multi-tenancy
in JPA 2.1 using JPA 2.0 or earlier. But there will be some caveats to
multi-tenancy in JPA that we will need to deal with, which I wanted to
start discussing.
First I think we should completely not use the existing multi-tenancy
stuff in our support for JPA 2.1 multi-tenancy. Hibernate
multi-tenancy, as it exists already, has some "overheads" thAt simply
are not needed for the JPA use-case. For example, in Hibernate
multi-tenancy (or "Saas multi-tenancy"), there is a need to know which
of multiple available pools to use for getting Connections for use with
particular tenants. But that is simply not needed for JPA multi-tenancy
(or "PaaS multi-tenancy") because that running JPA provider instance can
handle only one tenant at a time. Similar deal with second level cache
keys: no need to encode tenant id into the key. That app will hold only
one tenant's data (unless multiple apps share the same cache instances,
but that's handle-able by prefixing the regions per app/tenant).
If we do end up leveraging the existing multi-tenancy support, we will
additionally need to know the type of multi-tenancy in effect. Here I
mean this question of SaaS versus PaaS rather than the question of
SEPARATE_DATABASE versus SEPARATE_SCHEMA versus DISCRIMINATED.
JPA is proposing some limitations to available features based on the
type of multi-tenancy (if any) is used in the application that we should
go back and look at, even for our SaaS stuff. For example, in the
SEPARATE_SCHEMA the current proposal is to disallow the deployment from
referencing schemas/catalogs at all, which is a good idea. There is
also proposed limitations on native-sql queries such that:
1) they would not be portably available if using DISCRIMINATED, although
persistence providers could choose to support it if they can handle
injecting any needed discriminator fragments
2) could not reference schemas/catalogs in the SEPARATE_SCHEMA, which is
totally inline with the limitation on naming schemas/catalogs in general
in SEPARATE_SCHEMA.
Personally, I find all of the proposed limitations outlined above
reasonable. There is a question of whether we would want to support
native-sql queries in the DISCRIMINATED case. Take an example where the
user supplies a query like [select ... from CUST_TBL c]. Obviously we
need to limit that to return just their data, so we would need to
instead pass a query along to the database like [select ... from
CUST_TBL c where c.tenant = 'acme'] (assuming 'acme' is the current
tenant identifier). It is a lot to bite off to support this
unilaterally, because often folks are resorting to native-sql queries
because they need to leverage some db-specific SQL syntax/feature and
that is essentially impossible to properly parse and interpret. One
option is that we could instead allow a placeholder: [select ... from
CUST_TBL c where c.tenant = ${tenant}]. But even here we still have
difficulty with being able to guarantee that we catch all cases. So in
the end, I am not sure this is something we should be doing.
Anyway, if y'all have thoughts I'd like to hear.
--
steve(a)hibernate.org
http://hibernate.org
14 years
Re: [hibernate-dev] Identify Hibernate version
by Dmitry Geraskov
Thanks, Hardy!
Dmitry
10.04.2012 17:59, Hardy Ferentschik написал:
> Hi Dmitry,
>
> you are basically looking at the right place. For any released version of Hibernate Version#getVersionString()
> will return the release tag of the Hibernate version.
>
> If you are compiling the HEAD of the master branch the version you will see in the log is 4.1.0-SNAPSHOT.
> We are using bye code manipulation to inject the version at compile time. You find the code which does it
> under buildSrc of the checkout. It is a gradle plugin (InjectionPlugin).
>
> The version itself comes from build.gradle where the group- and artifact-if together with the version are defined.
> Something like:
>
> subprojects { subProject ->
> // ...
> group = 'org.hibernate'
> version = '4.1.0-SNAPSHOT'
> // …
>
> Hope this helps,
> Hardy
>
>
> On Apr 10, 2012, at 4:40 PM, Dmitry Geraskov wrote:
>
>> Hi, guys,
>>
>> could you please tell me how to identify hibernate version used at run time.
>> I expected to get it from org.hibernateVersion , but the code is:
>>
>> public class Version {
>> public static String getVersionString() {
>> return "[WORKING]";
>> }
>> ...
>> }
>>
>> Could you please help?
>>
>> Thanks,
>> Dmitry Geraskov
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
14 years
