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 <sa...@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.schei...@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.schei...@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 <emman...@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.schei...@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. > >>> > >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
