Could UUID be one of the default strategy when AUTO is requested
by Emmanuel Bernard
Hey,
I am throwing an idea, let me know what you think.
If the return type of the id property of an entity is either String or UUID, could we automatically consider one fo the uuid strategy as the one matching AUTO?
It would be useful for Hibernate OGM but I am also thinking that it makes equal sense to Hibernate ORM users.
Thoughts? I’m sure there are incompatibilities I have not think of.
Emmanuel
9 years, 10 months
index-many-to-any
by Steve Ebersole
Anyone used this mapping construct before? As far as I can tell, it is
incompletely defined. Unless I am missing something, it misses allowing to
map discriminator values to classes (meta-value).
What is more concerning that that is simultaneously allows re-defining the
discriminator type (meta-type).
Is this intentional for some reason?
9 years, 10 months
Fwd: Hibernate ORM modules published as major.minor and an alias for main
by Emmanuel Bernard
FYI
> Begin forwarded message:
>
> Date: 14 Jan 2015 17:30:59 CET
> From: Scott Marlow <smarlow(a)redhat.com>
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Subject: Re: Hibernate ORM modules published as major.minor and an alias for main
>
> Hi Emmanuel,
>
> On 01/14/2015 11:06 AM, Emmanuel Bernard wrote:
>> Hi Scott,
>>
>> In the f2f we discussed the idea of having ORM being published as major.minor and have an alias form main to the default WildFly targeted version.
>> Is that in and for which WildFly version?
>
> I created https://issues.jboss.org/browse/WFLY-4021 and https://github.com/wildfly/wildfly/pull/6883 which got merged into WildFly 9.0.
>
> The change is that modules/system/layers/base/org/hibernate/4.3/module.xml was added and contains:
> "
> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate.main" slot="4.3" target-name="org.hibernate"/>
> "
>
> I think this is wrong though, as it should be:
>
> "
> <module-alias xmlns="urn:jboss:module:1.3" name="org.hibernate" slot="4.3" target-name="org.hibernate"/>
> "
>
> I'll reopen and push a new pull request.
>
>
>>
>> I am just trying the catch up.
>>
9 years, 10 months
[OGM] Store objects as actual typed objects via the native grid format
by Emmanuel Bernard
In the forum came an interesting proposal for Hibernate OGM.
https://forum.hibernate.org/viewtopic.php?f=31&t=1037739&sid=9ee9d4772ac6...
Today I think OGM works quite well for document store and even Neo4J because they don’t have any schema and thus we can store the data in a natural fashion.
For k/v stores, it is so flexible that OGM imposes its tuple structure to represent the object. This is good enough but has a few drawbacks:
- to read the data back you need the OGM classes around or at least how they are structured
- being detyped, they tend to be hard to query by the k/v query capability
- we store more data than we could as we copy the column names in each entry
Some k/v stores do have the notion of “schema”. Infinispan uses Protobuf and ask the user t provide the proto schema. Coherence and Hazelcast uses the Portable Object Format (invented by the coherence guys AFAIK). Hibernate OGM makes no use of these. We could use these schema to express the Tuple (which is essentially a Map) but that’s not what people are looking for I think.
What people are looking for is a way to defined a set of schemas (protobuf or POF) corresponding to the entities and have OGM use the schema to store a given serialized entity. This solves the problems above, in particular the capability to use the native query options of the k/v store and the compactness.
I can see that being conceptually possible as long as we ignore associations. The schema would describe the properties, even the embeddable and collection of embeddable objects. As long as these “schema” library let us write the data in a untyped fashion, something akin to:
entityStructure = schemaLib.as(schemaId);
entityStructure.putProperty(“firstname”, tuple.get(“firstname”) );
addressStructure = entityStructure.addNestedObject(“address”);
addressStructure.addProperty(“city”, tuple.get(“address.city”) );
Note that the user here (see question c), also asks for the ability to denormalize the data and store a full object graph as one key and only a subset as a second key which is something we want to do but that we don’t have right now.
Thoughts?
Emmanuel
9 years, 10 months
GSOC ideas
by Sanne Grinovero
Do we have any suggestion for Google Summer of Code ideas?
We might be able to get sponsored (paid) students; as usual it's hard
to find tasks at the right level of difficulty.
For example, I'd love to get some help in the Solr/ElasticSearch
integration area but it would need to be a very good student for that.
My ideas so far:
# Migration of our new JPQL parser to latest ANTLR version (as an experiment)
# JBoss Forge integration for Hibernate Search
# CDI extensions
# New Faceting engine
# Automated performance regressions tests (develop benchmarks & setup
infrastructure)
# Taking advantage of efficient loading profiles (the JPA 2.1
feature): auto-generate the ones Search needs
We also need volunteers to mentor students in this area;
I'm happy to take one, but can't survive taking more :)
Sanne
9 years, 10 months
Slot name for modules of Hibernate OGM
by Sanne Grinovero
I just noticed that the main module for Hibernate OGM has slot="ogm",
while the various dialect extension modules use the "main" slot.
My understanding is that "main" should be reserved for the version
included in a specific application server version, so we'd better
avoid it to make it possible to eventually include OGM in WildFly and
still be able to differentiate versions.
The "ogm" slot also doesn't make it possible to use multiple versions,
which is ok now that there's a single release but won't be
sustainable.
Could we use the same label for all modules in a specific release, and
encode version in it too?
I propose using "ogm-{Major.Minor.Micro}".
Using the ".Micro" postfix might seem overzealous as micro versions
are supposed to be drop-in compatible but I'd rather be safe and be
able to be explicit; we could in addition provide an alias like we do
with Hibernate Search and Infinispan; this seems to be working quite
well so far.
Such an alias deploys a module which defines for say "ogm-4.1" should
look for "ogm-4.1.1": then applications can generally refer to
"ogm-4.1" and let the alias resolve it, or be more explicit if they
like so.
Sanne
9 years, 11 months
