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
