6.0 - Type redesign
by Jordan Gigov
I've been reading the wiki and email archives, and I have some notes
for what needs to be decided before it needs to become retrofitted.
After all, all that retrofitting is what the reason the types need to
be redesigned.
LiteralType.objectToSQLString is only used to append the DiscriminatorValue.
Can't it just work with regular binding to the PreparedStatement so
the unsafe interface can be removed?
A type should be able to define classes Interfaces and Abstract
classes that it can handle in their Java types.
This will enable implementing handlers for things like javax.script.*
objects that can have different providers, thus different class names
of the final object.
That would have to be a secondary check if no match is found by Java
class name, because it's slower and dangerous when binding
parameters to a query.
If stored as Class object references, they would have to be held in
WeakReference objects tied to a ReferenceQueue, so as not to
prevent garbage collection when a context is unloaded in a multi-context server.
If stored as Strings, there would have to be a call to Class.forName
for each, which if successful would have to check isInstance on the
object or isAssignableFrom on it's class (when evaluating DB model).
There are currently no notes on how to handle binding the values to a
PreparedStatement/CallableStatement.
There is also no mention of how java.sql.SQLType that was added in
Java 8 comes into play, which will help with vendor-specific types.
When converting the new types to a bindable object they will need
access to the Dialect and these methods of the java.sql.Connection:
createArrayOf
createBlob
createClob
createNClob
createSQLXML
createStruct
getClientInfo
getMetaData which returns DatabaseMetaData which can give access to
the java.sql.Connection if we're trying to abstract away from it.
Maybe also to:
setClientInfo
getWarnings when reading results from the database
getTypeMap
setTypeMap
On Thu Jul 21 15:27:49 EDT 2016 Steve Ebersole <steve at hibernate.org> wrote:
> I know we could get around this by splitting (or keeping split) the notions
> of ORM Type and JPA Type, but I would like to avoid that : this unification
> is going to be important to the SQM Criteria support.
Reading the description of javax.persistence.metamodel.Type, I'm not
sure it serves the same purpose as Hibernate's Type and that it should
be a super-interface of it.
In fact, starting to read the Metamodel API chapter where these
interfaces are defined, I'm fairly certain it's supposed to reflect
the structure of the persistence unit.
In other words, I don't think javax.persistence.metamodel.Type fits
anywhere in this picture and it's a different concept altogether.
As for OGM (which I've never used, but here's an idea) the problem
with SqlTypeDescriptor (discussed in end of June, as I read the mail
archives)
maybe could be turned into an extension of a more generic
StorageTypeDescriptor, and SQL would be just one type of storage? I
don't know
how that would work, since I've never had to use NoSQL and don't even
know if that makes sense.
Maybe the persistence context should provide the binders/extractors to
each type upon use.
9 years, 1 month
[OGM] Neo4j integration dependencies
by Davide D'Alto
The integration with Neo4j in OGM makes it possible for a user to
select the strategy that he wants to use to connect to an embedded or
remote Neo4j instance.
There are 3 possible options:
1) Embedded mode, Neo4j run in the same JVM
2) Remote via HTTP interface using RestEasy
3) Remote via the Bolt protocol using the neo4j-java-driver library
Everything is now in one single artifact meaning that for each case we
have more dependencies than needed, in particular for the remote
cases.
Possible solutions I can think of at the moment are:
1) Have different maven artifacts:
- We could have 3 artifacts: EMBEDDED, HTTP and BOLT
- or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve
the issue because w would still have
resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it
might be a good trade-off
We will need to share some resource so this approach might require
a Neo4j common library.
2) Make some dependencies optional (Need to test this, but it might work)
3) Use some maven plugin to generate different artifacts from the same
module. I haven't used this approach before so I'm not sure if it is
feasible.
4) ???
Any opinion about this?
Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190
Thanks,
Davide
9 years, 2 months
SQM - encoding type info into the tree
by Steve Ebersole
In SQM's domain metamodel we decided to follow JPA's guidelines in terms
of javax.persistence.metamodel.Metamodel. That is to say... a Type in SQM
describes a Java type not its database mapping, just as it is in JPA.
As a concrete example of the difference and its implication, consider a
Boolean attribute. The Type for that attribute would be
a BasicType<Boolean> which only describes the Java Boolean type; it
contains no information about how that value is mapped to the database (aka
it is not a "mapping type"). But this mapping information is important.
It is simply not enough to know that the value is a Boolean, we have to
know that it is "a Boolean mapped to a BIT" or "a Boolean mapped to a
CHAR(1)" etc.
As we are building the SQM, we ask the "consumer" (ORM, etc) to resolve
domain metamodel info for us. The ideal being that as as we build the SQM
tree in SQM we could encode "mapping type" information from the consumer
into the tree structure. But the problem is how to define access to a
"mapped type system" when SQM's type system is strictly domain-based.
Where this really becomes problematic is when determining the "implicit
type" for Expression nodes in the tree. Consider an example...
{code}
from Person p where p.active = ?1
{code}
The idea is that we really want to be able to infer the type of the "?1"
parameter expression based on its context in the query. Since it is used
as an operand of a equality predicate we know that its type should be the
same as the other operand, here: "p.active".
But this is where the domain-type/mapping-type split comes into play. At
the SQM level we have no notion of a "mapping type", so the fact that
"p.active" is "a Boolean mapped to a BIT" or "a Boolean mapped to a
CHAR(1)", which is really the information we want associated with the param
expression. All we can know from the SQM side is that "p.active" is a
BasicType<Boolean> and therefore "?1" should be to - but that is not enough
contextual info to handle binding that param properly.
I see a few options to address this:
1. Add a notion of "mapping type" to SQM's domain metamodel. The
"mapping type" would not be ORM-specific (aka, no expectation of JDBC).
Think of it more as a momento (pattern). This effectively creates a
complete parallel of ORM's type system though, which always feels like a
code smell to me.
2. Simply leave determination of an expression's "implicit type" out of
SQM. Resolving an expression's implicit type based on Type as defined by
JPA and currently by SQM is simply not expressive enough to be of any
value. As the SQM consumer processes the SQM tree it would make that
determination then.
9 years, 2 months
Array datatypes optional module
by Jordan Gigov
The feature is now ready for review.
JIRA issue HHH-10999, Pull request #1499
It is not 5.1-compatible, because it requires the Session object to be
passed as the WrapperOptions.
One test fails due to bug in core: HHH-11171.
I'm guessing a lot of type descriptors would fail those tests as well.
They've only been presumed to work so far.
9 years, 2 months
Re: [hibernate-dev] Adding a Byte Buddy byte code provider to Hibernate
by Steve Ebersole
Since this is gaining some traction, I think we need to start deciding:
1. whether to have Byte Buddy *replace* Javassist, or to have it as an
alternative impl
2. IIUC some of our issues could be alleviated by generating a Javassist
shaded jar. Should we consider that for Byte Buddy out the gate?
On Wed, Oct 12, 2016 at 3:36 PM Steve Ebersole <steve(a)hibernate.org> wrote:
> oops, guess this works better if I send it to the group ;)
>
>
> On Wed, Oct 12, 2016 at 1:09 PM Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
> Since this is gaining some traction, I think we need to start deciding:
>
> 1. whether to have Byte Buddy *replace* Javassist, or to have it as an
> alternative impl
> 2. IIUC some of our issues could be alleviated by generating a
> Javassist shaded jar. Should we consider that for Byte Buddy out the gate?
>
>
> On Tue, Oct 4, 2016 at 9:18 AM Steve Ebersole <steve(a)hibernate.org> wrote:
>
> I created https://hibernate.atlassian.net/browse/HHH-11152 to track this
>
> On Mon, Oct 3, 2016 at 6:55 AM Steve Ebersole <steve(a)hibernate.org> wrote:
>
> I'd also like to revisit the BytecodeProvider contracts. I wrote those
> really to fit CGLIB and Javassist and our legacy code around CGLIB
> specifically. But I'd like to revamp that to be more logical. So feel
> free to suggest any edits to the SPI that you feel make sense.
>
> We should also decide if we want to support both, or just move to
> ByteBuddy. If we support both, we will not be able to leverage things
> that ByteBuddy can do that Javassist cant (like you mention annotation
> retention). Personally I think we should just pick one and go with it.
> I can't imagine users generally care. However I do think the SPI still has
> merit as it makes it easier to experiment with alternatives/replacements
> later (as it made it easier for you here).
>
>
> On Mon, Oct 3, 2016, 6:43 AM Rafael Winterhalter <rafael.wth(a)gmail.com>
> wrote:
>
> Hi Steve,
>
> it is great to hear you are interested! By "proof of concept" I mean that
> I have not yet put much effort into it as I did not know if this was an
> option at all. I only wrote a very general implementation without testing
> it to see if there is anything missing in Byte Buddy that Javassist is
> offering and that you relied upon. Byte Buddy makes a few things different
> when it comes to manipulating existing code but this is not in the scope of
> what Hibernate is currently using Javassist for.
>
> I am more than happy to write a real BytecodeProvider using Byte Buddy. In
> a first step, I would simply mimic the current Javassist provider. In a
> later step, I would then try to apply a few optimizations to make the
> interceptor a bit more lean; this would benefit performance due to on
> inlining size and make it easier to debug. At this stage, we can also look
> into a few features that Javassist does not offer as for example annotation
> retention.
>
> I try to find some time in the next two or three weeks and get back with a
> prototype.
>
> Best regards, Rafael
>
> 2016-10-02 2:23 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>
> That's awesome that you were able to code something up Rafael. I will set
> aside some time next week to look this over.
>
> When you say "proof of concept" I am curious how complete you feel this
> is. You mentioned not dealing with the fast-class stuff, which is ok by me
> - as you say, this is not so much an issue anymore as it was back in JDK
> 1.4 :) More I mean in terms of both proxy generation support and bytecode
> enhancement. In regards to those 2, how complete do you feel this work is?
>
> And again, thanks for taking this on. This is something I have wanted to
> look at, but just could never find the time. Glad someone took this on.
>
>
> On Sat, Oct 1, 2016 at 10:25 AM Rafael Winterhalter <rafael.wth(a)gmail.com>
> wrote:
>
> Hello everybody,
>
> I was wondering how big the chances are to get a Byte Buddy bytecode
> provider into Hibernate? Byte Buddy has matured a lot over the last two
> years and it aims a lot on performance what is something Hibernate could
> benefit of. There are comparion charts posted on the Byte Buddy webpage. As
> a bonus, Byte Buddy is already ready for Java 9 and gives a lot of features
> for free, for example generic meta data retention and a possibility to
> retain annotations on subclassed types and overridden methods.
>
> I have written a simple proof of concept here:
> https://github.com/raphw/hibernate-bb without having tested it - I did not
> implement the fast class providers as I have learned after a lot of
> benchmarking that those do not improve performance on Java 8+ VMs anymore.
> Using such fast-classing rather pollutes the code cache than bring any
> benefit. The only advantage with code generation in this field comes when
> avoiding boxing what is not the case. But of course, I can implement
> something in Byte Buddy to apply such a fast-class mechanism.
>
> Let me know what you think. I am more then happy to help you with
> implementing such a provider. Other frameworks such as Mockito already use
> Byte Buddy on a large scale and made good experiences with it.
>
> Best regards, Rafael
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
9 years, 2 months
HBM migration suggestions
by Noel
Hi guys,
We have 200-ish hbm files we would like to convert to annotated classes. Is there any tool you guys recommend to tackle such a project ?
Thanks in advance for your time,
Noel
9 years, 2 months
Hibernate Validator 5.3.0.Final is out
by Guillaume Smet
Hi,
It's with great pleasure that I announce you the release of the final
version of Hibernate Validator 5.3.0.
There is a lot of activity on Hibernate Validator these days and we decided
to bring to the users several enhancements and bugfixes while we are making
progress towards Bean Validation 2.0 and Hibernate Validator 6.
See the announcement post
http://in.relation.to/2016/10/11/hibernate-validator-530-final-out/ for
more information about the release!
On a side note, if you are interested in defining the future of Bean
Validation, please come join us working on BV 2.0 here:
http://beanvalidation.org/.
--
Guillaume
9 years, 2 months
Hibernate OGM double release!
by Davide D'Alto
Good news!
We released Hibernate OGM 5.1 Alpha1 and 5.0.2 Final!
Hibernate OGM 5.0.2.Final now supports MongoDB 3.2 and it’s still
backward compatible with Hibernate OGM 5.0.1.Final.
Hibernate OGM 5.1.0.Alpha1 brings support for Neo4 in remote mode.
We also started to re-work the way Hibernate OGM groups operations
before running them; this reduce the number of calls and commands to
execute on the datastore, leading to better performance.
You can find more about these releases and how to get them in the blog post:
http://in.relation.to/2016/10/10/hibernate-ogm-5-1-alpha-and-5-0-2-released/
Thanks,
Davide
9 years, 2 months
