bryanhunt/mongo-emf

MongoDB - EMF Binding

mongo-emf's Issues

MongoInputStreaming causes an infinity loop while using EMF Edit Framework

The MongoInputStream#read() returns '0' which causes an infiity loop when EMF Edit Framework makes a HEAD request.

returning -1 solves the problem

MongoDatabase should have helper function for creating URIs

MongoDatabase should have the following helper functions for creating URIs:

URI createCollectionURI(String collection)
URI createObjectURI(String collection, String id)

Rename query bundle

I want the new query work to go into org.eclipselabs.mongo.emf.query, so I'm going to rename that bundle. Same goes for org.eclipselabs.emf.query.

MongoDatabase should default to "junit" database

MongoDatabase should have a default constructor that defaults the database name to "junit"

MongoUriHandlerImpl needs to trim fragments too

In case you have an URI with a fragment, the fragment needs to be trimmed too in MongoUriHandlerImpl#getCollection (line 136) to find the database provider in the mongoDatabaseProvider map.

Rename org.eclipselabs.mongo.junit

The bundle name for org.eclipselabs.mongo.junit should include emf as a qualifier, so I think it should be renamed to org.eclipselabs.mongo.emf.developer.junit

Tagged reading support

Tagged reading support was added to the MongoDB driver before it was intended to be released and does not work properly. The MongoDB folks are going to remove support from the next minor version of the driver and eventually add it back in when MongoDB supports tagged reads with sharding. The code is still there, just commented out.

Update your main page's listed update site for Workspace Mechanic

Hello,

I've moved Workspace Mechanic to git, and so, the update site location had to change as a side-effect. GIve http://workspacemechanic.eclipselabs.org.codespot.com/git.update/mechanic a try, as listed on your main page.

Add an option for cascade delete

It would be handy to have an option to cascade delete cross-document containment references. In a client / server environment, the server can do the deletes much faster than the client. The client would then do a cascade unload to clear out it's local cache.

Doesn't build

Plugin org.eclipselabs.mongo requires version 2.6.3 of com.mongodb:

Require-Bundle: com.mongodb;bundle-version="2.6.3"

But the version of com.mongodb from the workspace is 2.5.2:

Bundle-SymbolicName: com.mongodb
Bundle-Version: 2.5.2

Which should it be? And shouldn't you use Import-Package anyway instead of Require-Bundle?

IMongoDB service implementation is not thread safe

Create configuration for data normalization

EObjects saved with mongo-emf are persisted in a single mongoDB collection. If the EObject is a parent container of sub objects and this EObject is saved with mongo-emf the child EObjects are stored as subdocuments to the parent within a single document contained in a single mongoDB collection.

Depending on application performance requirements, ECore models may need to be saved to different resource collections on a Mongo DB. Currently, client code is required to manage this normalization of data, by saving and reading the subobjects to and from different collections. This is done using different resource uris for each of the child EObject targeted for a different collection.

Can this deployment wiring be automated? Can a generalized solution be offered for configuring MongoDBURIHandlerImpl so that saving of parent EObjects graphs will result in the saving of some or all of the EObject child objects to one or more different collections?

Enabling on-demand loading for large collections

When a InputStream is created (in MongoInputStream) with a query on the URI, all the collection is loaded at ressource creation time (line 93-94), which can be long in case of a query returning huge amount of elements.

With huge (several milions of elements), the EList performances are very poor (and not linear).

It would be nice to delegate this to the QueryEngine in order to permit a on demand load of the collection with eventual caching.

Thanks in advance for your comments and eventually proposals

Improve configuration through declarative services

Configuration of the Mongo instances should be possible through ConfigAdmin. I propose restructuring the code to take better advantage of declarative services and service configuration. IMongoDB will be refactored into IMongoFactory and the service will become a factory for instances of Mongo.

The changes should be structured such that users will still be able to use the code outside of an OSGi container.

Feature request - Mongo-emf maven dependencies

Hi

It would be great if there was maven dependencies of mongo-emf.

Thanks and regards

Queries with invalid operators should not return any results

If you create a query and happen to forget to put the value in ' ' (singleAttribute==4d), you will get back all entries in the collection.

Change OSGi services to use DS

It would be nice if all of the OSGi services used DS. Using DS can create some challenges with JUnit testing, so we will need to provide a nice way to make sure all services have been created prior to running any unit tests.

Unneccessary Require-Bundle in org.eclipselabs.mongoemf.api Manifest

There two require bundle directives:

org.eclipse.xtext.xbase.lib;visibility:=reexport,
org.eclipse.emf.ecore.xcore.lib;visibility:=reexport

They doesnt seem to have any use in the API.

Add support for EMF ID attribute

It would be nice to support the EMF ID attribute. If the ID flag is set on an attribute, then map the value of that attribute to the MongoDB _id key. Consideration needs to be given to the query engine since it would have to map the ID atribute name to _id.

Custom data type converters

The plugin already handles all the native mongo database data types, however, it is sometimes required to have customer converters to convert types or objects to/from mongo storage. For example the java.util.Calendar class (and therefore java.util.GregorianCalendar) is not handled by mongo natively, but it still needs to be stored. Some my want to store it as a long value, others as an ISO8601 string. Providing a custom data type conversion mechanism will enable the user of the plugin to decide how data is stored in mongo.

Create a builder API

Extract the core features of the plugin to an API that can be used generically to convert EObjects to DBObjects and vice versa.

By doing this it will enable users of the conversion library to use the code in their own persistence frameworks, and allow converted objects to be customized individually before persistence. This would also have the side effect of removing the dependency on the IMongoDB object for those using the code outside of OSGi, and let users handle persistence in their own way.

Refactor unit tests

he model for the unit tests started out ok, but now, it's confusing as to what is containment vs non-containment vs cross-document containment, etc. The model needs to be refactored so that the reference names reflect what is really happening. The refactoring should include the use of the MongoUtil functions.

Refactor query unit tests into separate bundle

Since we are working on a new query engine, the existing query unit tests need to be moved to their own bundle. The old query engine will be deprecated and eventually removed for 1.0.

eClassCache is not used

The eClassCache passed to the builder is never used by the builder.

Refactor IQueryEngine to support field selection

More advanced query languages provide the ability to select which fields in a document are returned from a MongoDB query.

Currently the IQueryEngine provides a return type of DBObject. This is sufficient to find documents in a collection, with DBCollection.find(DBObject ref) but in order to select which fields of the documents are returned a second DBObject must be returned - DBCollection.find(DBObject ref, DBObject fields).

Change IQueryEngine to support returning a second DBObject.

This will affect the client usage of IQueryEngine in the MongoInputStream class.

Problems in DBObjectBuilderImpl#buildDBObject with References that have EOpposite

The current code
if (!reference.isTransient() && eObject.eIsSet(reference))
buildReference(eObject, dbObject, reference);
doesnt take care about bi-directional references. This causes errors when you use EOpposites.
This code fixes the problem
if (!reference.isTransient() && eObject.eIsSet(reference)
&& !(reference.getEOpposite() != null && reference.isContainer()))
buildReference(eObject, dbObject, reference);

Junit bundles still use require bundle

If you change the JUnit bundles require bundle on org.hamcrest.core to import package, you have to add org.hamcrest.core to PDE's Automated Management of Dependencies list to get the code to compile, and even then, the unit tests will not run because the import org.hamcrest cannot be found. I've opened a bugzilla against PDE to track the problem.

Current design does not properly support authentication

Authentication is rather broken. While investicating the problem, I found that the design does not support per database authentication, only per server authentication. I will refactor IMongoProvider and IMongoLocator into IDatabaseProvider and IDatabaseLocator to properly support per database authentication.

query.mongodb does not exist in repository

The bundle query.mongodb does not exist in the repository http://bryanhunt.github.com/mongo-emf/releases/0.8.0/index.xml.gz