[hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests

[Sanne Grinovero]

That's a good point. This first abstraction was built around
Cache-centric approaches, so that's reflected in the [test]API method
names, but there are no "Cache" types in the interface you have to
implement.

I think you should be able to ignore the inappropriate names and still
fullfill the contract of
org.hibernate.ogm.test.utils.TestableGridDialect ?

Taking for example:

/**
 * @param sessionFactory
 * @return the number of elements stored in the entity "cache"
 */
int entityCacheSize(SessionFactory sessionFactory);

You just have to extract the number of entities stored ..

Considering a Document based NoSQL such as MongoDB you can still think
of each document as a value, so it can conceptually degenerate in to a
Key/Value model.

If you can just get it to work fine, after you send a pull request we
can then think about improving the method names to be more
appropriate.

Please let me know if this doesn't fit..

Cheers,
Sanne

On 14 March 2012 15:03, Guillaume SCHEIBEL <guillaume.scheibel at gmail.com> wrote:
> 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 at 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 at 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 at 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.
>>>
>>
>