[OGM] Rethinking of naming around the map datastore
by Emmanuel Bernard
The Map datastore provider is named MapBasedDatastoreProvider and his
short cut is mapbased.
To me it looks weird to use the suffix based. We don't use
InfinispanBasedDatastoreProvider for example.
I'm inclined to:
- rename MapBasedDatastoreProvider to MapDatastoreProvider
- rename mapbased to map
Anyone against it?
Emmanuel
13 years, 10 months
be gone NPE in HqlSqlWalker.createFromJoinElement and AS7-5555
by Scott Marlow
Hi,
In AS7-5555, Ondřej is looking to let the person writing the application
know what is wrong in a different way than throwing an NPE.
Throwing a new HibernateException("you did it wrong") might be more
informative.
Any arguments against doing that?
Also, any suggestions for what the exception message should be?
Scott
13 years, 10 months
SessionFactory building, 5.0-style
by Steve Ebersole
The initial design I had for building a SessionFactory using the new
metamodel was 3 steps:
1) build ServiceRegistry
2) build Metadata
3) build SessionFactory using both ServiceRegistry and Metadata
This changed a little as actually implemented in the metamodel branch:
1) build "boot strap" service registry
2) build basic service registry
3) build MetadataSources
4) build Metadata
5) build SessionFactory using both basic service registry and Metadata
I would like to change this slightly based on JPA 2.1 work and
integrating that with containers (mainly through planning with Scott for
JBoss AS).
<background>
Essentially Scott and I made a change proposal to JPA EG for how managed
EMF bootstrapping happens to better account for stuff in the container's
environment not being available until certain times. It is a typical
"hole in the interaction of specs" deal. Long story short, we want to
make boot strapping of an EMF into 2 distinct phases. Whether or not
that gets accepted/approved, we will implement this approach for
Hibernate EMF bootstrapping and JBoss AS will leverage it.
The 2 phases are meant to account for container resources not being
available or the need to delay classloading.
</background>
The changes I propose would just be ordering:
-- phase 1 --
1) build "boot strap" service registry
2) build MetadataSources
-- phase 2 --
3) build basic service registry
4) build Metadata
5) build SessionFactory using both basic service registry and Metadata
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
Re: [hibernate-dev] (no subject)
by Steve Ebersole
Also, I have been thinking that there really ought to be different
types of "integrators". Not sure what we gain by forcing
MetadataContributingIntegrator, ServiceContributingIntegrator,
TypeContributingIntegrator, etc to extend Integrator
On Sat 18 Aug 2012 05:50:29 PM CDT, Steve Ebersole wrote:
> The general idea is good. But not really getting the point/purpose of
> having both before and after hooks.
>
> On 08/17/2012 01:12 AM, Strong Liu wrote:
>> I'm thinking add the interface below, with it, modules like envers
>> can choose either before or after the metamodel get processed to hook
>> into its own extending mappings
>>
>>
>> public interface MetadataContributingIntegrator extends Integrator {
>> /**
>> * Allow the integrator to alter the {@link MetadataImplementor}
>> BEFORE {@link MetadataSources} get processed.
>> * <p/>
>> *
>> * At this stage, metamode ( like {@link
>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is not
>> available yet.
>> * This is a good time to add the custom sources into
>> {@MetadataSources} and get it processed by Hibernate Metamodel.
>> *
>> * @param metadata The Metamodel which is going to be completed
>> by processing MetadataSources.
>> * @param source Meta data sources to be processed.
>> */
>> public void beforeMetadataProcessing(MetadataImplementor
>> metadata, MetadataSources source);
>>
>> /**
>> * Allow the itnegrator to alter the {@link MetadataImplementor}
>> AFTER @{@link MetadataSources} get processed.
>> * <p/>
>> *
>> * At this stage, metamode ( like {@link
>> org.hibernate.metamodel.spi.binding.EntityBinding} etc. ) is bindded.
>> * So, it depends on the integrator to manually create metamodel
>> and add it to {@link MetadataImplementor} or modifiy the
>> * existing one.
>> *
>> * @param metadata
>> * @param source
>> */
>> public void afterMetadataProcessing(MetadataImplementor metadata,
>> MetadataSources source);
>> }
>>
>> downside is, envers with old metamodel calls
>> Configuration.buildMappings() again during the integration phase, so,
>> its created hbm xml can be processed (again) before SF create, but
>> with new metamodel, it is hard to do that I think ( or too time
>> consuming )
>>
>> and to create envers own metamodel ( hbm ) it needs to know the
>> hibernate type of entity property, which can be easily get from
>> Entitybinding but hard / duplicated to resolve from source by envers
>> itself, so it seems we should choose "afterMetadataProcessing"
>>
>> but envers' hbm creation involves lots of code and pretty complicated
>> ( to me :) it's better to reuse those code and choose
>> "beforemetadataProcessing" and let new metamodel to take care of that.
>>
>> thoughts?
>>
>>
>> On Aug 2, 2012, at 12:17 AM, Hardy Ferentschik <hardy(a)hibernate.org>
>> wrote:
>>
>>> On 31 Jan 2012, at 10:55 PM, Sanne Grinovero wrote:
>>>
>>>> Why is the "annotation indexing" discussion part of the metamodel?
>>> Why not? We are using Jandex in the new metamodel which is a
>>> annotation index/repository
>>>
>>>> I initially understood that a replacement of commons-annotations was
>>>> being developed, which would be nice for Search too as Search does not
>>>> and should not depend on Hibernate ORM.
>>> as Strong already said, there is no replacement module for
>>> commons-annotations. There is no
>>> need for it.
>>>
>>> And yes, Search should imo also switch to Jandex, however, it can
>>> initially just create its own index.
>>> Of course it might be nice to be able to use a Jandex index passed
>>> to it via the integrator spi. Different story though.
>>>
>>> --Hardy
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> -------------------------
>> Best Regards,
>>
>> Strong Liu <stliu at hibernate.org>
>> http://about.me/stliu/bio
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
master -> metamodel
by Steve Ebersole
I want to merge master to metamodel again. Gail already asked me to
wait until next week. So I will plan on holding off until Monday..
Any concerns with doing it Monday?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
4.1.7
by Steve Ebersole
Tomorrow is the timebox for 4.1.7 release.
Anything you want in 4.1.7 please be sure to get finished up and pushed
to the 4.1 branch.
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
byteman
by Strong Liu
org.hibernate.test.annotations.xml.ejb3.NonExistentOrmVersionTest STANDARD_OUT
14:19:50,895 INFO SchemaExport:343 - HHH000227: Running hbm2ddl schema export
14:19:50,896 DEBUG SchemaExport:353 - Import file not found: /import.sql
14:19:50,896 INFO SchemaExport:405 - HHH000230: Schema export complete
14:19:50,896 INFO DriverManagerConnectionProviderImpl:156 - HHH000030: Cleaning up connection pool [jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;MVCC=TRUE]
org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest > testOrm1Support STANDARD_OUT
TransformListener() : unexpected exception opening server socket java.net.BindException: Address already in use
org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest > testOrm1Support STANDARD_ERROR
java.net.BindException: Address already in use
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 10 months
Jira issue links
by Steve Ebersole
Saw something pretty cool today in Jira. Not sure when it was added,
but you can now link Jira issues to random urls.
For example, here is an issue I linked to its JBPAPP counterpart :
https://hibernate.onjira.com/browse/HHH-7563
Was thinking we might want to do that for GitHub pull-requests as well
and get rid of the JBoss Jira plugin...
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
