Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
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.
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: 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. Does it? Surely we don't have much than 10 elements in these collections for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
Ok, I was affraid of having a lot more data into the DB. The stored data type will be just simple object or some embedded object could be present too (to know if I have to go all over the field map to find relationnal data) ? Guillaume 2012/3/15 Emmanuel Bernard emman...@hibernate.org On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: 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. Does it? Surely we don't have much than 10 elements in these collections for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
On 15 March 2012 16:58, Guillaume SCHEIBEL guillaume.schei...@gmail.com wrote: Ok, I was affraid of having a lot more data into the DB. The stored data type will be just simple object or some embedded object could be present too (to know if I have to go all over the field map to find relationnal data) ? I think that right now you're the only person knowing how OGM is storing that in MongoDB :) If in doubt, please add a test. Sanne Guillaume 2012/3/15 Emmanuel Bernard emman...@hibernate.org On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: 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. Does it? Surely we don't have much than 10 elements in these collections for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
Yes I know that, but you know way better than me the core suite test :) that's why I'm asking 2012/3/15 Sanne Grinovero sa...@hibernate.org On 15 March 2012 16:58, Guillaume SCHEIBEL guillaume.schei...@gmail.com wrote: Ok, I was affraid of having a lot more data into the DB. The stored data type will be just simple object or some embedded object could be present too (to know if I have to go all over the field map to find relationnal data) ? I think that right now you're the only person knowing how OGM is storing that in MongoDB :) If in doubt, please add a test. Sanne Guillaume 2012/3/15 Emmanuel Bernard emman...@hibernate.org On 15 mars 2012, at 17:04, Guillaume SCHEIBEL wrote: 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. Does it? Surely we don't have much than 10 elements in these collections for a given test. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
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
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
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] OGM-123 Support MongoDB as datastore - Unit tests
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) ? 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 ? Thanks Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
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. 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. Cheers, Sanne Thanks Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] OGM-123 Support MongoDB as datastore - Unit tests
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
