0.6.0 Released

[John Nunemaker]

Just pushed 0.6.0. Some major changes so listen up. :)

1. Switched to object ids by default for _id type

This is the biggest change. I was using the string representation of object ids as I didn't want to force people to convert strings to object ids when querying. Because of some changes to FinderOptions, MM is now smart enough to do this automatically for you. 

The default _id type is now ObjectId which uses Mongo::ObjectID behind the scenes. If you have production data that you don't want to convert to object ids, you can just declare _id as a string and all will work as it did before.

# backwards compat example

class Foo

  include MongoMapper::Document

  key :_id, String

end

This change should make MM play much nicer with the other language drivers and conforms more closely to the mongo way. You can still use custom string id's as well (or any _id type for that matter).

# custom string id example

class Foo

  include MongoMapper::Document

  key :_id, String

end

foo = Foo.new(:id => 'awesome')

foo.id # 'awesome'

foo.using_custom_id? # true

2. find returns nil, find! raises exceptions

find now returns nil when a document is not found by id instead of raising an exception. If you want to raise DocumentNotFound, you can use find! with a bang. A few people raised the point that this is more consistent and I agree.

find(id) # returns nil if not found

find!(id) # raises exception if not found

Same goes for find with multiple ids.

3. Setting database for document

To set the database for a document you must now use set_database name instead of database. This is only if you are using a different database than the default (MongoMapper.database).

class Foo

  include MongoMapper::Document

  set_database_name 'foo'

end

4. Other Changes/Fixes

* added support for :class as option on association in place of string class_name which makes even more dynamic stuff possible

* moved validates inclusion and exclusion of to validatable and incremented required validatable version

* added case_sensitive option to validates_uniqueness_of. For now this drops down to $where.

* validations can be skipped when saving. save(false) just like AR

* fixed pagination with :conditions

* several ruby 1.9 fixes, still not officially supporting but the brave are welcome

* fixed mmconsole which wasn't working

* added human_name for formtastic compatibility

* added some documentation

[Felipe Coury]

John,

Nice work!

Here's one thing that broke: foreign keys. But it was a simple fix for me, since I don't have anything in production yet...

The issue I had is reproduced by this code:

class User

  include MongoMapper::Document

  

  key :login, String, :required => true, :unique => true

  

  many :servers, :foreign_key => "user_id"

end

class Server

  include MongoMapper::Document

  

  key :user_id, String

  key :ip, String

  

  belongs_to :user

end

This was not passing some tests, where:

user = User.new(:login => "xyz")

user.save

server = Server.new(:ip => "blah")

user.servers << server

user.save

user.servers # => Was OK, but after 0.6.0 was []

My fix was to change the Server's user id to object:

class Server

  include MongoMapper::Document

  

  key :user_id, Object

  key :ip, String

  

  belongs_to :user

end

And my tests pass again, but that may not be that transparent.

That's all :-)

Cheers,
--
Felipe Gonçalves Coury
CTO, Webbynode - Serious Hosting for Developers
http://webbynode.com

[Sho Fukamachi]

John, can you comment on whether Felipe's approach here is the best practise way to do it?

Are there are performance/indexing ramifications for changing from strings to these mysterious Object IDs?

thanks. And awesome work!

Sho

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "MongoMapper" group.
> For more options, visit this group at
> http://groups.google.com/group/mongomapper?hl=en?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

[John Nunemaker]

I was told the performance implications are minor but the bigger deal
is compatibility with other drivers and such. And it is the more
mongodb way.

> --

[Sho Fukamachi]

I meant should we be making foreign keys of class Object in the way Felipe demonstrates:

eg

>>> My fix was to change the Server's user id to object:
>>>
>>> class Server
>>> include MongoMapper::Document
>>>
>>> key :user_id, Object
>>> key :ip, String
>>>
>>> belongs_to :user
>>> end

Sorry for not explaining myself better. Thanks for the answer to the performance question.

Sho

[John Nunemaker]

No, they should actually be ObjectId. All keys from now on should be
that unless you have data already that you can't delete or don't want
to migrate using String ids.

[Sho Fukamachi]

Hey John,

Can we have a convenience method to get the id of a document in the ObjectID format?

perhaps something like this

doc.id.class => String
doc.mongo_id.class => Mongo::ObjectID

That would be handy since you need the ObjectID form when you go and do upserts, etc, which require dropping to the driver.

cheers,

Sho

[Sho Fukamachi]

Awesome. Thanks for the info.

[John Nunemaker]

There already is one. _id will return object id, id returns string
representation.

> --

[Stephen Eley]

On Tue, Nov 17, 2009 at 8:22 AM, John Nunemaker <nune...@gmail.com> wrote:
> No, they should actually be ObjectId. All keys from now on should be
> that unless you have data already that you can't delete or don't want
> to migrate using String ids.

If we use other data types, e.g. integers, is it likely to cause us
problems down the road? (I'm thinking specifically of a Twitter app
that I'm building. Since Twitter's already giving me primary keys on
every user and tweet, my intention was just to use their ID as my ID.)


--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

[Sho Fukamachi]

Oh, I see .. great! Thanks a lot for all the answers.

[John Nunemaker]

Other data types should be fine to use now. Though I'd probably still
use ObjectId's for primary keys and then just have another key for
tweet_id that is an integer or whatever. Just my 2 cents.

[John Nunemaker]

No problem! :)

[Wojciech Piekutowski]

On Nov 17, 3:53 pm, John Nunemaker <nunema...@gmail.com> wrote:
> There already is one. _id will return objectid,idreturnsstring
> representation.

Could you write a bit more why #id does to_s on _id object? What's the
reasoning behind this? Can't #id be just an alias to #_id?

>
> On Tue, Nov 17, 2009 at 8:37 AM, Sho Fukamachi <sho.fukama...@gmail.com> wrote:
> > Hey John,
>

> > Can we have a convenience method to get theidof a document in the ObjectID format?

>
> > perhaps something like this
>
> > doc.id.class =>String
> > doc.mongo_id.class => Mongo::ObjectID
>
> > That would be handy since you need the ObjectID form when you go and do upserts, etc, which require dropping to the driver.
>
> > cheers,
>
> > Sho
>
> > On 15/11/2009, at 3:52 PM, John Nunemaker wrote:
>
> >> Just pushed 0.6.0. Some major changes so listen up. :)
>
> >> 1. Switched to object ids by default for _id type
>

> >> This is the biggest change. I was using thestringrepresentation of object ids as I didn't want to force people to convert strings to object ids when querying. Because of some changes to FinderOptions, MM is now smart enough to do this automatically for you.
>
> >> The default _id type is now ObjectId which uses Mongo::ObjectID behind the scenes. If you have production data that you don't want to convert to object ids, you can just declare _id as astringand all will work as it did before.

>
> >> # backwards compat example
> >> class Foo
> >>   include MongoMapper::Document
> >>   key :_id,String
> >> end
>

> >> This change should make MM play much nicer with the other language drivers and conforms more closely to the mongo way. You can still use customstringid'sas well (or any _id type for that matter).
>
> >> # customstringidexample

> >> class Foo
> >>   include MongoMapper::Document
> >>   key :_id,String
> >> end
>

> >> foo = Foo.new(:id=> 'awesome')
> >> foo.id# 'awesome'

> >> foo.using_custom_id? # true
>
> >> 2. find returns nil, find! raises exceptions
>

> >> find now returns nil when a document is not found byidinstead of raising an exception. If you want to raise DocumentNotFound, you can use find! with a bang. A few people raised the point that this is more consistent and I agree.

>
> >> find(id) # returns nil if not found
> >> find!(id) # raises exception if not found
>
> >> Same goes for find with multiple ids.
>
> >> 3. Setting database for document
>
> >> To set the database for a document you must now use set_database name instead of database. This is only if you are using a different database than the default (MongoMapper.database).
>
> >> class Foo
> >>   include MongoMapper::Document
> >>   set_database_name 'foo'
> >> end
>
> >> 4. Other Changes/Fixes
>

> >> * added support for :class as option on association in place ofstringclass_name which makes even more dynamic stuff possible

[John Nunemaker]

Hmm...there was a reason originally. I was thinking it was related to
rails but rails uses to_param so it shouldn't matter if id is an oid
and to_param just calls id.to_s.

Anyone have any complaints with me switching id to return the oid
instead of the oid.to_s?

[scottmotte]

I'd prefer id to return the oid as you've said.

On Nov 20, 7:56 am, John Nunemaker <nunema...@gmail.com> wrote:
> Hmm...there was a reason originally. I was thinking it was related to
> rails but rails uses to_param so it shouldn't matter if id is an oid
> and to_param just calls id.to_s.
>
> Anyone have any complaints with me switching id to return the oid
> instead of the oid.to_s?
>
> On Fri, Nov 20, 2009 at 10:22 AM, Wojciech Piekutowski
>

[Sho Fukamachi]

No complaints from me, I think that behaviour is preferable.