MongoUriHandlerProvider can handle just one MongoDatabaseProvider

[Mark Hoffmann]

Hi,
I wanna use MongoEMF with more than just one database. For that the MongoUriHandlerProvoider should reference to the database providers using 0..n dynamics in the components.xml instead of 1..1 static. Can you tell me, if this is intended? And if it is, why?

In my opinion it should work with dynamic refernces too.

Mark

[Bryan Hunt]

It looks like the code was intended for the cardinality to be 1..n dynamic and it was an oversight on my part to make it 1..1 static. Please open an issue or (even better) submit a PR.

Bryan

> --
> You received this message because you are subscribed to the Google Groups "MongoEMF" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mongoemf+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mark Hoffmann]

Hi Bryan,

thank you, I will make the change.

Further I would like to know, what do you think about supporting the latest mongo driver in version 3.x. I would try to OSGify the jar. And the Import-Package Version have to be updated and the client properties have to be checked at the first step.

Is there any idea to make the MongoEMF, eModeling, eMongo part of an Eclipse project like, similar like Teneo?

mARK

[Bryan Hunt]

Hi Mark,

I would like to update the code to support the latest MongoDB driver.  The driver should already be an OSGi bundle - it just needs to be put into a repository to be easily consumed by p2 and Bndtools.  One additional change I think I want to make for 0.9.0 is to move all of the EMF persisted metadata to an embedded object.

As for creating an Eclipse project, that might be nice, but I don’t see that happening until there are multiple committers on these projects.  The overhead of being an Eclipse project is significant.

Bryan

[Mark Hoffmann]

Hi Bryan,

I have made some bugfixes and created a pull request (user axtmann :-)). I took a look into the latest mongo driver. The Mongo guys did some major changes.

1. User can not be authenticated via DB.authenticate anymore, which is currently done in the MongoDatabaseProviderComponent
2. Credentials are given as list in the MongoClient  constructor. There is a method getCredentialsList in the MongoClient, but I dont now if it is a modifiable list, I will take a look into it
3. Mongo#getDB is deprecated we should use MongoClient#getMongoDatabase instead. Therefore we can now a MongoDatabase object instead of the DB object
4. If we use MongoDatabase instead of DB we have no DBCollection anymore but a MongoCollection

It looks as it is just a rename of classes.

Mark

[Mark Hoffmann]

Hi,

unfortunatly, the MongoClient#getCredentialsList is an unmodifiable list. That means, that all credentials for all databases have to be available in the MongoClientProviderComponent, because the list of credentials have to be given to the MongoClient in the constructor :-(. Maybe we should use the modify-callback in the component to submit new credentials for new databases via ConfigAdmin. The existing credentials from the current client instance in the component could be used via MongoClient#getCredentialsList and create a new MongoClient instance then. The bad thing I see with this solution is that not only the MongoDatabaseProvider has to be configured. Further the corresponding MongoClientProvider has to be updated when using authentication.

Mark  

[Bryan Hunt]

This sounds like a huge step backwards.  I’ll open a support ticket and see if there is any chance of getting the old behavior brought back.  If not I’ll probably re-design the whole client service.  Not looking forward to that.

Bryan

[Bryan Hunt]

I talked with MongoDB support.  There are security implications of the old authentication mechanism.  The current design is the way forward.  eMongo needs a 2.0 API design.  I, or someone else, should open an issue to track this and discuss the design.  Maybe morph the database provider into a credential provider and change the reference to static - just thinking out loud here.

Bryan

[Mark Hoffmann]

... or leave it like it is and: 

- Remove just the authentication from the database provider. 

- Introduce a CredentialProvider that can be consumed by the MongoClientProviderComponent (0..n static)

- CredentialProvider provides one or more MongoCredentials for one or more clientIds (MongoClientProvider)

The database provider would do nothing else than just return a database (I think it is ok). MongoClientProvider, MongoDatabaseProviderand MongoCredentialProvider are well separated. So if a database provider needs authentication, a MongoCredentialProvider can be used for one or more clientId's.

Mark

[Bryan Hunt]

That’s probably a good way to go.

Bryan