Data, data, everywhere, nor any ORM that fits
updated about 4 years ago; latest suggestion about 4 years ago
In our Ruby applications of today we have to retrieve, process and present data from many different sources (Relational DBMS, NoSQL DBMS, REST services in XML, REST services in JSON, non-RESTful web services, proprietary document formats), sometimes even all in the same application.
In this talk, I aim to display the evolution of the libraries and frameworks that have been created to reduce the headaches involved with dealing with data (many of which will be familiar) before presenting a new collection of libraries for source-agnostic data handling that is being worked on right now - DataMapper 2.
The technologies I'll talk about (some in more detail than others!):
- The Rails Way: ActiveRecord (of course), ActiveModel, ActiveResource
- The NoSQL Way: Mongoid, CouchPotato
- The RESTful way: RestClient/HTTParty
- The Backend Agnostic Way: DataMapper (version 1)
- The Future Way: DataMapper 2
Also interested in this. In recent projects I've found myself ditching ORM libraries as I've found I didn't need them, especially when working with Mongo, and that they constrained and polluted the data-model too much (I'm looking at you, ActiveRecord).
I've been using a simple repository pattern and PORO's using Virtus, but am probably re-inventing the wheel and would certainly be interested in what else is out there.
Just to reiterate Tom and Paul, I'm very interested in hearing about DM2; less interested in reliving the pain I already experience every weekday.
Like Tom, I'm (all too!) familiar with the pain, and I'm most interested in hearing about what's new in version 2.
You allude to using DM2 to access disparate services through a similar interface; that part sounds particularly intriguing.
I should add that I'm personally much more interested in hearing about The Future Way than in dwelling on the pain of the past. I already know the pain!
DM2 seems to consist of several gems and many separate moving parts, which is a good thing, but makes it harder to understand as a whole. I'd be really interested in a good explanation of how these pieces fit together, what they collectively achieve, and how this reduces the obvious headaches of Active Record.
Sure - I don't want to dwell for a long time on the existing solutions, this is really intended to provide more information about what's being developed/what's different about DM2 rather than being a fully comprehensive analysis of what's already available.
I'll try and make that clearer in the proposal, thanks!
This sounds nearly like two talks - a historical overview and a deep dive into DataMapper 2. I don't think you can treat both halves fully while maintaining audience attention.
Could you limit the historical overview by perhaps briefly pointing out just 3 issues with old ORMs, then moving forward to show how DataMapper 2 handles them?
Would you be able to suggest ways of deciding which ORM is the most suitable for a given project?
Yup, some hints about how best to select an ORM suitable for the data sources being used in a project sounds like a good idea.
Or is it DataMapper 2 all the way...?
Well, perhaps! I think that DataMapper 2 is an exciting approach to the problems we face in many modern applications. I hasten to add that it's by no means ready yet (let's see where it is come April I guess ;-)) but I can certainly see it gaining a lot of popularity once it is. To my mind, working with a single coherent API and being able to relate data across disparate data sources is certainly a powerful proposition.
This does sound interesting. Would you be able to suggest ways of deciding which ORM is the most suitable for a given project? Or is it DataMapper 2 all the way...?
This sounds very interesting. I'd like to hear about how DataMapper 2 can solve some common pain points, especially with regard to the ongoing discussion on how to separate your domain logic from concerns about persistence.