Sessions sharing Connections
by Steve Ebersole
Reference https://hibernate.onjira.com/browse/HHH-7020 and
https://hibernate.onjira.com/browse/HHH-7090...
Essentially, having 2 sessions share a JDBC connection is currently
broken. Adam, Lukasz and I discussed this on the mailing list a few
months ago and Shawn has been helping me investigating the last few
days. The solution end solution is to have the 2 sessions share both
the TransactionCoordinator and LogicalConnection, but use separate
JdbcCoordinators.
We could get away with them sharing a JdbcCoordinator as well, but that
opens up (slight) potential concurrency issues if the 2 sessions are
used concurrently. The concurrency issues here are not on the same
level as those if using a session concurrently. Mainly JdbcCoordinator
manages the "current JDBC batch" if the session is using JDBC statement
batching. Concurrent access could mean batch circumvention (aka, 1
statement executed in the batch instead of the batch size) if both
sessions are performing writes concurrently.
All the above is a bit specific, but the ultimate question/decision here
is that in order to not reuse JdbcCoordinators requires *major* SPI
changes. Basically we need to invert the relationship between
JdbcCoordinator and TransactionCoordinator. Currently Session holds a
TransactionCoordinator and that TransactionCoordinator is responsible
for managing the JdbcCoordinator. The "proper" change would require
that instead Session hold a JdbcCoordinator which is responsible for
managing a TransactionCoordinator.
A consideration here is that these are SPIs and should not really be
changing between point releases. But another thing to consider is that
these particular SPIs were added in 4.0, so they are relatively new, and
that, in this particular case at least, they are just plain wrong.
What do y'all think between these 2 options?
--
steve(a)hibernate.org
http://hibernate.org
13 years, 12 months
Re: [hibernate-dev] unmappable character for encoding ASCII
by Strong Liu
corrected
https://github.com/hibernate/hibernate-orm/commit/199fae5feee6186d8a4ad7b...
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
On Mar 19, 2012, at 10:42 PM, Hardy Ferentschik wrote:
> :-) I did not try this one
> Well, converting all the affected files should work then
>
> --Hardy
>
> On Mar 19, 2012, at 3:25 PM, Strong Liu wrote:
>
>> okay, I find it, Windows-1251 for Cyrillic alphabets
>>
>> thanks BBEdit's reopen using encoding function :D
>> -------------------------
>> Best Regards,
>>
>> Strong Liu <stliu at hibernate.org>
>> http://about.me/stliu/bio
>>
>> On Mar 19, 2012, at 10:15 PM, Hardy Ferentschik wrote:
>>
>>>
>>> On Mar 19, 2012, at 3:01 PM, Strong Liu wrote:
>>>
>>>>
>>>> On Mar 19, 2012, at 9:56 PM, Hardy Ferentschik wrote:
>>>>
>>>>> why does it say then "Execution failed for task ':hibernate-envers:generateJpaMetamodelClasses'."
>>>>> Confusing message at the very least.
>>>>
>>>> dont' know about that, but it also fails when i call compileJava directly
>>>>
>>>>>
>>>>> do the files look correct when you ope them in the editor?
>>>>>
>>>>
>>>> nope, does it look correct on your side?
>>>
>>>
>>> no. I would say it is not UTF-8 to begin with. This is case for iconv
>>>
>>>> iconv -f <whatever> -t UTF-8 <files>
>>>
>>> The problem is the whatever. If you use the wagon encoding you end up with some garbage, but
>>> at least it would be UTF-8. I tried a couple of source encodings, but none gives results where I would say
>>> that's probably it.
>>>
>>> You could try to use iconv with for example ISO-8859-1 and see if it compiles then. At least you would know that
>>> the problem is the actual encoding.
>>>
>>> --Hardy
>>
>
13 years, 12 months
unmappable character for encoding ASCII
by Strong Liu
any idea?
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/configuration/metadata/CollectionMetadataGenerator.java:97: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/configuration/metadata/CollectionMetadataGenerator.java:97: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/configuration/metadata/CollectionMetadataGenerator.java:97: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/EntityConfiguration.java:34: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/EntityConfiguration.java:34: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/EntityConfiguration.java:34: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/OneToOneNotOwningMapper.java:36: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/OneToOneNotOwningMapper.java:36: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/OneToOneNotOwningMapper.java:36: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/ToOneIdMapper.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/ToOneIdMapper.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/ToOneIdMapper.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/entities/mapper/relation/lazy/ToOneDelegateSessionImplementor.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversCollectionEventListener.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversCollectionEventListener.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversCollectionEventListener.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversEventListener.java:44: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversEventListener.java:44: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/BaseEnversEventListener.java:44: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostCollectionRecreateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostCollectionRecreateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostCollectionRecreateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostDeleteEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostDeleteEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostDeleteEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostInsertEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostInsertEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostInsertEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostUpdateEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostUpdateEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPostUpdateEventListenerImpl.java:35: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionRemoveEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionRemoveEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionRemoveEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionUpdateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionUpdateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/event/EnversPreCollectionUpdateEventListenerImpl.java:33: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/AuditQueryCreator.java:38: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/AuditQueryCreator.java:38: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/AuditQueryCreator.java:38: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/AbstractAuditQuery.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/AbstractAuditQuery.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/AbstractAuditQuery.java:50: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/EntitiesAtRevisionQuery.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/EntitiesAtRevisionQuery.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/EntitiesAtRevisionQuery.java:40: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/RevisionsOfEntityQuery.java:39: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/RevisionsOfEntityQuery.java:39: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/query/impl/RevisionsOfEntityQuery.java:39: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/tools/Tools.java:47: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/tools/Tools.java:47: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
/home/stliu/projects/hibernate-orm/hibernate-envers/src/main/java/org/hibernate/envers/tools/Tools.java:47: unmappable character for encoding ASCII
* @author Hern???n Chanfreau
^
54 errors
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':hibernate-envers:generateJpaMetamodelClasses'.
Cause: Compile failed; see the compiler error output for details.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 11.524 secs
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 12 months
JtaPlaform classes as internal?
by Emmanuel Bernard
Because you need to know the JtaPaltform class name to fill up hibernate.transaction.jta.platform, I find it curious that these classes are in internal.
I might decide to delete one of them and not care as they are in internal but that will impact the user.
I see two options:
1. create subclasses in a non internal package
2. create shortcuts for the built-in platforms (weblogic, websphere-5, websphere-6, etc)
I like option 2 better as it makes configurations more readable.
WDYT?
14 years
Re: [hibernate-dev] [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
by Scott Marlow
On 03/06/2012 02:27 PM, Galder Zamarreño wrote:
> So, to summarise all of this. What I suggest is this:
>
> - Short term:
> The "quick fix" I suggest in http://lists.jboss.org/pipermail/infinispan-dev/2012-March/010317.html
Do we want to try this (requires a new build of Infinispan I think)? Or
should applications workaround the issue until we can reach the
medium/long term?
>
> - Medium term:
> Have a way to pass in marshalling configurations per cache manager and per-cache (or an abstraction of it), which allows the right class resolver to be passed in. (***)
> https://issues.jboss.org/browse/ISPN-1367
ISPN-1367 is targeted to Infinispan 5.2, any idea of the target release
date for that? I'm curious as to which AS release it might align with.
>
> - Long term:
> https://issues.jboss.org/browse/ISPN-1413
>
> (***) I still don't fully understand how web apps don't have the same issue as 2LC of not seeing Infinispan classes (Reminder: we're not talking about the contents of the cache, but about the Infinispan classes themselves).
https://github.com/jbossas/jboss-as/blob/master/web/src/main/java/org/jbo...
appears to be wired to use Paul's ClassLoaderAwareClassResolver.
>
> On Mar 6, 2012, at 8:19 PM, Galder Zamarreño wrote:
>
>>
>> On Mar 6, 2012, at 8:06 PM, David M. Lloyd wrote:
>>
>>> On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
>>>> On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
>>>> </snip>
>>>>> To work around this, we typically store MarshalledValues in the cache - which are marshalled/unmarshalled using a marshalling configuration specific to the application (e.g. via a ModularClassResolver using the ModuleLoader of the deployment unit).
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j...
>>>>
>>>> Isn't a class resolver and a class loader, functionality wise, doing the same thing? I wonder if a custom classloader could not be built that delegates to a ModularClassResolver...
>>>
>>> No, not really. A class loader loads a class, given a name. But a
>>> class resolver loads a class given a name *and* stream information. The
>>> modular class resolver reads the stream information to know which class
>>> loader houses the class in question. This is critically important
>>> because it's possible (common even) for more than one class to exist in
>>> an AS instance with the same name. And there is no single class loader
>>> which has visibility to all classes which could potentially be stored in
>>> a cache.
>>>
>>> Yes, accepting a class loader to use is a powerful feature. However it
>>> *should* just be a convenience abstraction over a more fundamental
>>> feature which allows a class resolver to be set.
>>
>> Thanks for the clarification, makes sense.
>>
>> So, if I understand this correctly, Infinispan should really be enhanced to accept global and per-cache class resolvers, or more globally, as paul suggested below, marshalling configuration instances (or abstractions of them).
>>
>> I think https://issues.jboss.org/browse/ISPN-1367 should be reporpoused to do this.
>>
>>>
>>>>> So, essentially Infinispan itself only ever has to marshal/unmarshal a byte[] wrapper - so the AS has full control over the marshalling process.
>>>>>
>>>>> I would recommend that the 2LC do something similar, and include a mechanism for providing a MarshallingConfiguration per persistence unit.
>>>>
>>>> Possibly…
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>
>>>
>>> --
>>> - DML
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
14 years
[HV] Release plan for a version compatible with Bean Validation 1.1.0.Alpha1
by Emmanuel Bernard
Hi Hardy, Gunnar and all,
I am thinking that we should get the ball rolling on an implementation of Hibernate Validator that supports Bean Validation 1.1.0.Alpha1 so that we can gather feedback.
When do you think we can get an HV Alpha supporting the changes? What about a month?
Emmanuel
14 years
Infinispan tests
by Steve Ebersole
Running the hibernate-infinispan tests I am seeing 2 output directories
showing up in the hibernate-infinispan directory (aka, not
hibernate-infinispan/target/...). Namely, I see
hibernate-infinispan/ObjectStore and
hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we can
change where those directories get created?
--
steve(a)hibernate.org
http://hibernate.org
14 years
Hibernate Search 4.1 CR2 is out
by Emmanuel Bernard
We have just released Hibernate Search 4.1 CR2. This is mostly a bug fix release but let's mention better compatibility with JBoss AS 7 and better write throughput.
Read more at http://goo.gl/2OV8w
Emmanuel
14 years
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
by Guillaume SCHEIBEL
Hi,
I'm implementing the MongoDBTestHelper and I have a question
Most of the methods implents are referencing a "Cache". Either for Infispan
or for EhCache there is a specific implementation of Cache so should I
implement mine because I think there isn't any cache into the
mongodb-java-driver ?
Guillaume
2012/3/14 Guillaume SCHEIBEL <guillaume.scheibel(a)gmail.com>
> Ok I see, according to what you said guys, I'll first remove all tests I
> added and run/work with the core test suite. if some mongodb test will be
> needed (I think about replica set management or map/reduce but that's for
> later) I will create them into the module directly.
>
> I think I'll be able to make a new pull request this week (probably
> tomorrow or friday). What is the best practice about that, making 1 commit
> like OGM-123 mongodb support (with the dialect, the TestHelper, etc) or
> making specific commits like I did (or tried to do) for the previous pull
> request ?
>
>
> Guillaume
>
> 2012/3/13 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
>>
>> On 13 mars 2012, at 20:19, Sanne Grinovero wrote:
>>
>> > Hi,
>> > I'm answering inline:
>> >
>> > On 13 March 2012 16:39, Guillaume SCHEIBEL <
>> guillaume.scheibel(a)gmail.com> wrote:
>> >> Hello,
>> >>
>> >> About unit tests during the development phase on OGM-mongodb, I'm
>> wondering
>> >> what is the best way.
>> >> Actually, I've developped some specific tests (CRUD mainly) because I
>> was
>> >> not aware of the existing test suite. So my question is: should I
>> remove
>> >> all my tests and just use core test or should I let them to test
>> specific
>> >> points (like @Embdedded into @Embedded) ?
>> >
>> > I think it's a good idea to have custom tests as well, currently the
>> > ones "inherited" from the core module are really testing only the core
>> > bits.
>> > Feel free to add more tests in your custom module, but maybe check you
>> > don't have duplicates.
>> > Also if they are not specific to your module, maybe you should add
>> > them to the core module instead so that they help covering all
>> > "dialects".
>>
>> My feeling is that most tests should be in core as the "TCK" to make sure
>> each dialect is safe or see when it fails. So I would favor to move tests
>> into core as much as possible.
>> In your example, there is nothing MongoDB specific about @Embedded and we
>> should make sure we indeed support that for all dialects.
>>
>> The tests that could stay in your won modules are tests that ensure that
>> the embedded object is properly put in the document and not else where.
>> That does not make much sense right now but I imagine that for collection
>> of embeddable and when we support metadata driven datastore specific
>> tuning, we will want to test such things. (ie collections of embeddable are
>> in the document in mongo and outside in a different key in say Infinispan.
>>
>> >
>> >> And am I wrong if I say that to launch the core test suite I just have
>> to
>> >> add a simple hibernate.properties into src/test/resources/ of the
>> mongodb
>> >> module and launch maven with the test goal ?
>> >
>> > You'll have to add a hibernate.properties, but also create an
>> > implementation of org.hibernate.ogm.test.utils.TestableGridDialect
>> > and edit org.hibernate.ogm.test.utils.TestHelper at line 42 to add
>> > your knownTestDialects.
>> >
>> > To see how to implement a TestableGridDialect, I guess your best guide
>> > is to look into the EHCache and Infinispan implementations for
>> > examples.
>> >
>> > You're beta-testing these instructions, feel free to ask more details
>> > I might have forgotten, so I can make a good wiki page out of this.
>>
>> Let's open a wiki page to document these discoveries that will help
>> wannabe datastore contributors.
>> Title: "How to write a Datastore in Hibernate OGM" in the hibernate ogm
>> subspace.
>>
>> BTW, in eclipse and in intellij, you can say that you run a given (set
>> of) test based on the classpath of a specific module. That will let you run
>> the test with the mongodb settings stored in your hibernate.properties file.
>>
>>
>
14 years
