You’ve probably seen this, but it speaks to my original comment about the term “nosql” -
http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html

To quote Eric Evans, “My regret however isn’t about what the name says, it’s about what it doesn’t. “

thanks,
bill

Good idea. One thought, we use this for lots of other import tasks besides ActiveRecord. In fact, ActiveRecord isn’t a dependency at all in this library. However, I think I could add that feature in as a configuration option that is off by default. Thanks for the suggestion!

Justin

More details on the mailing list - http://groups.google.com/group/mongomapper/browse_thread/thread/2bebc5bdc4bb54a7

Not sure if that’s intentional or not, but after creating an index on 2M documents, it was wicked fast.

VertexDB: http://github.com/stevedekorte/vertexdb

@Austin: I’m not sure where in the post I argued that traditional RDBMSs should be included under the NoSQL banner. I totally agree, however, that we shouldn’t abandon the advances that RDBMSs (and graph databases, and other tools) have made over the last thirty+ years. Unfortunately, however, there *are* people who disagree with the principle of using the right DB for the job – or more accurately, think that RDBMSs are *always* the right DB, regardless of the job. That’s the crowd I’m arguing against here (well, technically I’m also arguing against the much smaller crowds that say ‘always use a document DB,’ too, but I don’t know if those parties attract anyone.)

@BJ: I love MySQL, and you’ve certainly got a good point that extra features don’t disqualify it from being a great K-V store. My intuition is that an application dedicated to being a K-V store will be superior to something that’s not so dedicated, but I’m betting that somebody out there is benchmarking this even as we speak. It might turn out that MySQL is better than [insert flavor-of-the-month K-V store here], but at this point that’s an open question. I’m happy to admit that using the right DB for the job depends on knowing (with empirical backing) *which* DB is the right one :)

You say “why would you want to use them for non-relational data?”. MySQL has a blazingly fast network protocol, as well as being able to write data to disk super fast (comparable to Tokyo Tyrant and Redis). It has great libraries for interacting with in almost every programming language, a massive user base, robust replication, and almost everyone that has every written a web app has experience with it. I’ve yet to see any concrete evidence (sorry if I don’t take your word for it being a “bad idea") as to why it’s not a good key/value store. Just because it has more features doesn’t mean that you have to use them nor does it mean it’s a bad piece of software.

I’m not a fan of the term NoSQL as a blanket term.

This post seems to broaden the scope of the movement to include RDBMS and SQL… kind of makes for a confusing flag to wave…

Throwing away relational, graph, and hierarchical database theory is a bad idea.

Your NoSQL is a bit like the Structured programming movement (late 60s)… who is going to disagree if NoSQL means “use the right db theory for the job”.

NoSQL should live or die by the merit of distributed key-value stories, neo4j and other DBs that take advantage of CS theory shouldn’t be considered NoSQL.

On the other hand, plenty of apps could use a simpler data model. What initially excited me about document-oriented, schema-less databases was that data modeling could become much more sane. Applications that might require dozens or hundreds of relational tables can typically be modeled with many fewer different document collections.

I don’t really care whether there is one or many open standards relevant to NoSQL, as long as any given flavor makes data portability through an open standard possible.  So it is good to hear (and I probably had read that previously and just forgotten it) that CouchDB and MongoDB data can be grabbed with JSON easily.

I guess I just mean to raise data portability as something people should choose when considering various data store solutions…

Cheers,
Walter

To answer your question for a couple of cases, though: CouchDB and MongoDB both store their data as JSON (or binary JSON), which is about as simple an export format as you can get.

I’m in the “wait and see what rises to the top and why” crowd.  Basically, at the next point I begin a project or an addition to a project that requires a data store aspect, I’ll evaluate what my options are and choose what I think is the best tool for the job.  NoSQL or an RDBMS?  I’ll consider what best suits the project.

All common sense, but often people latch onto trends or defend their previous perspectives despite their common sense.

My question about NoSQL:

Where is the Open Standard for the community?

I’m might have missed it because I haven’t done a lot of homework on this, but the beauty of SQL is its relative interoperability.  Yes, there are vendor specific extensions that can bite you if you want to change software, but if you forego those it ain’t that hard to move between the various RBDMS programs at this point.  This boils down to a vendor independent standard that is ubiquitous.

At this point when considering a tool I always ask “how do I get my data in and how can I get it out again if I want to move it somewhere else?”

Cheers,
Walter

I really tried getting into HomeBrew but just did not have the skill for the roller coaster. As I was saying to one user in the comments. Do what works best for you. For me in particular I really like having things not intertwined with Apple so upgrades feel more in my control. Some claim that HomeBrew does the same. Do what works best for you. Know your options.

Maybe I just didn’t read enough, but I looked at Homebrew, and it seemed that I still had to download and provide packages myself, or am I just missing something?

Some of my favorites:
-Me too, on Fever for RSS
-SugarSync for backing up multiple systems & across systems (Dropbox & ZumoDrive for kicks, as well)
-LittleSnapper + Ember (for screen grabbing and inspiration)
-Postbox for email
-SpaceSuit (for different wallpapers on different spaces)

Thanks!
Justin

Trouble is the user argument evaluates to nil inside the helper if I try and pass it a User instance. Passing in a string is fine so I guess there’s some strange scoping issue afoot. Any ideas?

def current_account
@current_account ||= begin
unless session[:current_account_id].to_i < 1
Account.find_by_id(session[:current_account_id])
end
end
end

but it’s less readable and acts differently - it defines @current_account regardless of session[:current_account_id] which is not very aesthetic either.

BTW it’s really cool that you can type:

nil && whatever.else.here_as_long[:as_it_is].synactically{|valid| ruby}

and “run” it without ruby complaining.

* DB2
* MSSQL
* Postgres
* SQLite
* Firebird
* Sybase
* Informix
* Riak
* Scalaris
* Dynomite
* Ringo
* PStore
* Hypertable
* Cloudbase
* RDDB
* HypergraphDB
* ...

I’d hoped that the point of the post would come through regardless of the specific databases mentioned, though.

Sigh

@Joshua:
1. I doubt we would ever do authsub, we will probably add oauth at some point. We usually add stuff when we really need it on something. Anyone is more than welcome to add the functionality in a fork on Github and we will consider pull requests.

2. Caching is done at different places by memoization. Anything beyond that is up to the users of the library.

1) Tightly-coupled dependent objects – I wrote a survey-building application that handled multiple-choice questions as questions with embedded choices.

2) Domains with variable data (which you identified) - rows full of NULLs make me cry, so any time I have variable data (or STI) my document-db wheels start turning.

3) One-offs, like the app I run on my local machine to track sites around the web where I’ve left comments. I used to use SQLite for these, but they’ve generally got very flat (non-relational) persistence mappings, so a relational DB would be overkill - and being able to avoid migrations makes it just that much easier to get going.

I actually haven’t needed to resort to a document DB for full-text searching or for scalability, but there are still good reasons to pull one in.

Two quick questions:
1 - Do you plan on adding support for Authsub instead of simple login?
2 - How, if at all, is caching handled?  It seems that there are a lot of times when duplicate data would be pulled that caching could fix.

Thanks,

Josh

Foo.collection.clear will empty the collection where Foo is a class that includes MongoMapper::Document.

@Peter - That is what tests are for. ;) Also, MongoDB already has some features available for managing your data such as renaming collections and such and they have more planned for the future like removing/renaming keys.

I love the idea of the flexibility available, but part of me wonders what a mess the data can/will end up in after a couple of years, unless the programmers are very strict in their usage…

Just curious.  What is the actual problem you’re trying to solve?  Are you running an application where an RDBMS failed to scale for you?  Or where a map/reducable key-value store with enhanced querying and relational features (the exciting future of this in my perspective) was a necessity?

as additional resource, you can find two opensource projects using mongomapper here:
http://gitorious.org/shapado/shapado
and
http://gitorious.org/menki/menki