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

[Guillaume SCHEIBEL]

TestableGridDialect.associationCacheSize is killing me !
Because it's not possible to perform a query without knowing the field
name. So I can forget about "I want to know the amount of document which
contain a field (except '_id') whose type is ObjectID"

The same query with "contain a field named 'myField' ..." works.

I could probable iterator over all collections and all documents but it
definitely bursts the tests performances.

Any idea ?

Thanks & cheers
Guillaume

2012/3/14 Sanne Grinovero <sanne at hibernate.org>

> 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.
> >>>
> >>
> >
>