*** Important for those pointed as Mongoid master ***

[Durran Jordan]

This is your commit reference: 2f56dbdf614e453a6105fed0f90e8ecf12be9298

That is the last commit before the merge of the moped-integration branch, going forward on master from that commit no longer uses the 10gen driver.

Important things to note:

- Remove any references to bson_ext, bson, or the mongo gems.

- If you are using GridFS, you cannot go past this commit as it is not currently supported in Moped or Mongoid.

- If you are dropping down to the driver level for anything, you've got a syntax change. Please see the Moped README about this until we have the new docs out with the official releases. https://github.com/mongoid/moped

- The entire mongoid.yml has changed. You will be getting validation errors now when the mongoid.yml is loaded to instruct you what to change. You can generate a new one via rails g mongoid:config - the new yaml has comments all over it to help you get running quickly. You can also see a sample here: https://github.com/mongoid/mongoid/blob/master/spec/config/mongoid.yml

- The persist_in_safe_mode option has been removed. You now provide this in the mongoid.yml on your session configuration options.

- #safely and #unsafely have been removed. You now can use #with to provide safe/unsafe options. Ex: Band.with(safe: true).create

- Index definition syntax has changed - you will get an error you tell you how to fix this.

- The store_in macro syntax has changed - you will get an error to tell you how to fix this as well.

- There may be some gem incompatibilities we have not addressed yet by sending them pull requests. The following is a list of gems we have tested and are currently compatible that have a dependency on mongoid itself: carrierwave-mongoid, kaminari, state_machine, fabrication. We have a target list of all other gems we will be going through next week and submitting pull requests to to bring them up to date if they need to change - most likely none of them will.

- For logging you simply only need to change the log level in Moped: Moped.logger.level = Logger::DEBUG

Pay attention to the CHANGELOG (https://github.com/mongoid/mongoid/blob/master/CHANGELOG.md) - especially the Major Changes section under 3.0. New features are there with examples, as well as bug fixes. Note that ALL bug fixes that went into 2.4.x releases are in master (3.0), but are listed under each respective 2.4.x release in the CHANGELOG.

If you have questions, problems, ping me here.

Cheers!

d

[victorgrey]

> - If you are using GridFS, you cannot go past this commit as it is not
> currently supported in Moped or Mongoid.

Will this affect carrierwave-mongoid's GridFS support?
Tx,
=vg

[Durran Jordan]

You will *not* be able to use a storage of :grid_fs if you are using carrierwave. No GridFS support at all. This is because is it not a core database feature of MongoDB, it is implemented in the drivers.

2012/4/14 victorgrey <victo...@gmail.com>

[victorgrey]

> You will *not* be able to use a storage of :grid_fs if you are using
> carrierwave. No GridFS support at all.

The problem for me is that carrierwave-mongoid does not seem to offer
any way to store files in MongoDB except GridFS.

Any suggestions?

Thx,
=vg

[Durran Jordan]

You're not limited to GridFS with Carrierwave - we use it to store in S3 as well as on the filesystem.

2012/4/15 victorgrey <victo...@gmail.com>

[Alexey Savartsov]

What if I keep getting

Routing Error
uninitialized constant Moped::BSON::InvalidObjectId

for every url after updating to current master (and fixing all errors
by following mongoid instructions)?

--
С уважением, Алексей Саварцов

[Durran Jordan]

Are you catching that error somewhere in your app? If not, can I see your Gemfile so I can try to hunt down the gem that's doing it.

2012/4/15 Alexey Savartsov <asava...@gmail.com>

[Alexey Savartsov]

Oh, yes, that was rescue_from BSON::InvalidObjectId, thanks for hint.

[Alexey Savartsov]

Another small problem connected with previous one. Will new mongoid
check validity of id before serializing it and raise some specific
error? Now entering something shorter than normal id lead moped to
raise ArgumentError in lib/moped/bson/object_id.rb:16 which I believe
will result in 500 in production.

[Durran Jordan]

I'll modify it to raise a specific error - probably with the same name.

2012/4/16 Alexey Savartsov <asava...@gmail.com>

[Alexey Savartsov]

Thank you for your time!

[ara howard]

this totally pissed me off until i read

  http://www.mongodb.org/display/DOCS/GridFS+Specification

and are 1hr into implementing my own GridFS interface.

i assume you'd accept a pull request for Moped::GridFS?

[Tal Atlas]

I know it's pretty fast either way. But why not support bson_ext? In
my tests it's 5-6x faster than Moped::BSON::ObjectId.

On Apr 14, 6:09 am, Durran Jordan <dur...@gmail.com> wrote:
> This is your commit reference: 2f56dbdf614e453a6105fed0f90e8ecf12be9298
>
> That is the last commit before the merge of the moped-integration branch,
> going forward on master from that commit no longer uses the 10gen driver.
>
> Important things to note:
>
> - Remove any references to bson_ext, bson, or the mongo gems.
>
> - If you are using GridFS, you cannot go past this commit as it is not
> currently supported in Moped or Mongoid.
>
> - If you are dropping down to the driver level for anything, you've got a
> syntax change. Please see the Moped README about this until we have the new

> docs out with the official releases.https://github.com/mongoid/moped

[Durran Jordan]

Had you thought that it was actually implemented in Mongo, like most are lead to believe? :)

Bernerd and I talked about this at length and decided we didn't want it in Moped, but would be okay with it in a separate gem. I had tentatively created the repo "ghostly" for this, but hadn't gotten around to doing anything yet... So we'd like to no matter what the case have it separated since we want it to be clear to people what they are getting themselves into when using it.

So in short, no we don't want it in Moped, but were planning on supporting something as a separate gem.

2012/4/17 ara howard <ara.t....@gmail.com>

[Durran Jordan]

Can you send me a link to a gist those tests? Our benchmarks aren't showing this.

https://gist.github.com/1844063

2012/4/17 Tal Atlas <swimmi...@gmail.com>

[Durran Jordan]

Ah you must be referring to ObjectId generation... Yeah bson_ext is much faster at doing that. We'll probably add our own c extensions soon since I don't think on that specific front we can make it faster in pure Ruby.

2012/4/17 Tal Atlas <swimmi...@gmail.com>

[ara howard]

i was concerned about interoperabilty with 'mongofiles' but my tests are covering that

 https://gist.github.com/2407396

a bit annoying that the signature for Binary has reversed...  but a shim like this *should* prepare for the move.

my strategy, right not is systematically kill refs to GridFS, BSON, Mongo, etc, and do everything in terms of Mongoid as much as is possible.  we log to mongo and cache file uploads in mongo before pushing to s3 and those bits of our code hit Mongo/BSON directly... ;-(

so - sound like a sane strategy?

ps.  carrierwave straight to s3 is broken if you have > 1 app server because the tmp files are cached on the local file system so a GET/POST might miss *unless* your load balancer has session affinity.  because of this stuffing tmp files into mongo is really sweet.  then sweep to s3 in the background one file at the time (preserving memory and cpu too).

[James Cox]

Serious question…

why do you cache in mongo/gridfs? do you see performance for this, or
is it just to maintain a local file store before propagating to s3?

james

--
James Cox,
Consultant, Raconteur, Photographer, Entrepreneur
t: +1 347 433 0567  e: ja...@imaj.es w: http://imaj.es/
talk: http://twitter.com/imajes photos: http://500px.com/imajes

[ara howard]

bit of both.  for smallish apps where only, say, a logo is uploaded it's nice to have those files in mongo  -it makes debugging production way simple.

when things get serious and we need to go s3 it's then also nice to have a central queue doing the sweeping/posting/resizing to keep mem/cpu low and elimnate issues of eventual consistency (not on s3 for one person but visible to another)

[ara howard]

you know, even though this is true, they sure make it seem core

  http://www.mongodb.org/

front page stuff.... hrm.  perhaps it's an implementation details that it's written in drivers... maybe that doesn't make it 'not core' ... ?