Morphia 0.93 DAO api

[David Marko]

Would be very nice if method protected com.mongodb.DBCollection
collection(); is not protected but public. In many situations one have
to accesss DBCcollection methods outside of DAO class and this would
be useful.

David

[Mauricio Garavaglia]

Hi David,
In which situations do you need to access the collection outside the DAO? I think the dao internals dont need to be exposed.
Bye!

Mauricio

--
To unsubscribe, reply using "remove me" as the subject.

[David Marko]

In my application bootstrap, which runs when my application starts, I
would like to create(ensure) indexes. And I need something like below.
For my purpose I have created getCollection() public method in my DAO.

####
BasicDBObject options=new BasicDBObject().append("background",
true);
BasicDBObject q=new BasicDBObject();
q.put("datum_zadani", 1);
taskDAO.collection().ensureIndex(q,options);
####

One additional question, can I define database name somewhere in more
global way than in DAO constructor? In very common cases, when one
application means one mongo database, I have to repeat it again and
again. But I certainly miss something here.

David

On 8 dub, 15:42, Mauricio Garavaglia <mauriciogaravag...@gmail.com>
wrote:

[Scott Hernandez]

There is now another data access interface, the Datastore. It provides a type-safe, generic interface for working with mongodb. It is a good base to use for creating your own DAO abstractions.

It has a set of ensureIndex() methods for this type of thing. We can easily add support the background flag (or IndexOpts). There is also the declarative @Indexed annotation. It is still a new feature but might be a more consistent way to manage indexes for you. For now @Indexed only works for single property indexes directly on the entity. There is an issue to expand support for embedded and multi-field indexes: http://code.google.com/p/morphia/issues/detail?id=28 

We are in the midst of transitioning the docs to explain things in more detail, for the new features and interfaces.

[Ólafur Gauti Guðmundsson]

Hi David,
So far I've solved this by creating an ensureIndexes() method in MyDAO
(extends DAO<T,K>), which is a @Singleton created and managed by
Google Guice.

But I will look into this and add better indexing support to the DAO.

Regarding the Database name, if you are extending the DAO then you can
just create a constant in a class somewhere and reference it. However,
if you are using the DAO directly, then I can understand that this
becomes repetetive.

I am going to look into adding the database name to the entity
annotation. That way we could by default retrieve both the name of the
database and the collection from the @Entity annotation (or something
similar), which is defined in a single place.

Thanks for the feedback.
Regards,
OGG

[Scott Hernandez]

2010/4/8 Ólafur Gauti Guðmundsson <oli....@gmail.com>

Hi David,
So far I've solved this by creating an ensureIndexes() method in MyDAO
(extends DAO<T,K>), which is a @Singleton created and managed by
Google Guice.

But I will look into this and add better indexing support to the DAO.

Regarding the Database name, if you are extending the DAO then you can
just create a constant in a class somewhere and reference it. However,
if you are using the DAO directly, then I can understand that this
becomes repetetive.

A constant is always a good idea, or an enum if you have multiple databases you use.

 

I am going to look into adding the database name to the entity
annotation. That way we could by default retrieve both the name of the
database and the collection from the @Entity annotation (or something
similar), which is defined in a single place.

I'm not sure an annotation is a good place for specifying the database name. This seems like the information you would want to provide with the connection properties (host:port, timeout, connection pool size, db, etc.). For dev, testing, staging, and production you are going to want to be able to use different values; that shouldn't be embedded in your entities.

[Mauricio Garavaglia]

@Scott right, I don't see an annotation with the db name as the best approach neither. That will make integration tests a nightmare :)

@David If you wan't to instantiate the DAO by hand (without guice, spring, etc.) please consider implementing a factory so you dont DRY the name. Regarding the ensureIndex(), maybe you should move that inside the DAO initialization, (constructor, block initialization, using the factory or any DI mechanism)

Bye!

Mauricio