ORMs look like sonething that violates Occam s razor
What ORMs have taught me: just learn SQL (2014)
211–220 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#212One of the many reasons I love Elixir Ecto: it is a pretty small abstraction on top of SQL. Gets out of your way and let's you write SQL in elixir
OMG YES, I LOVEE Ecto!.
it lets you create beautiful sql like declarations
``` payment_types = from(s in Ecto.assoc(order_cycle, :splits)) |> join(:left, [s], p in assoc(s, :payments)) |> select([s, p], %{ type: p.type, card_type: p.card_type }) |> Repo.all() ```
its the first database library that makes queries easy to compose together. On top of that transactions are a snap to put together thanks to Ecto.Multi
Re: What ORMs have taught me: just learn SQL (2014)
#213"...They are an acceptable way to represent a data definition, but a poor way to write queries and a bad way to store object state." Rails perspective: Pump your brakes there, friend. This claim depends completely on your application's needs. I write web apps for research that don't need to scale and don't need lighting performance. I have built apps that ended up needing some optimized-SQL-versus-ActiveRecord experimentation, and sometimes, writing raw queries is certainly worth it. AR has been evolving for 15 years, is extremely useful, and all that is needed for many use cases. We're not all trying to do the same thing.
Re: What ORMs have taught me: just learn SQL (2014)
#214Will tend to agree with the author. Initially ORMs can save time when developing as you get an easy mapping between objects and the database. However in practise ORM tends to give you quite horrible JOINs that quite frankly are hard to understand for humans. Further more I think that ORM can lead to a bad practice in the sense that you do not need to think about your data layout first. But for database performance da…
This is completely false. The joins I do in the ORM are completely transparent to me as a developer and there is no mismatch whatsoever. The data layout and data migrations are well described.
And I have, at most, a half dozen difficult queries which require serious optimization, and that optimization isn't defined by the query but by the indexing and storage strategy for the tables in question.
Re: What ORMs have taught me: just learn SQL (2014)
#215Since 2014 we've gotten new tools to play with.
For example, Ecto isn't technically an ORM but it lets you do ORM-like things. It's Elixr's data mapping and query language tool. It happens to be one of the nicest "I need to work with data" abstractions I've ever used.
It's a bit more typing than ActiveRecord and even SQLAlchemy, but you feel like you're at a good level of abstraction. It's high enough that you're quite productive but it's low enough that it doesn't feel like a black box.
You get nice benefits of higher level ORMs too such as being able to compose queries, so you can design some pretty compact and readable looking functions, such as:
def eligible_discounts(package_id, code) do
__MODULE__
|> for_package(package_id)
|> with_discount()
|> active()
|> usage_count_less_than_usage_limit()
|> after_starts_at()
|> before_ends_at()
|> maybe_code(code)
end
I think Ecto's biggest win was having the idea of changesets, schemas and repos as separate things. It really gives you the best of everything. A way to ensure your data is validated but also flexible enough where you can separate your UI / forms from your underlying database schema. You can even choose not to use a database backend but still leverage other pieces of Ecto like its changesets and schemas, allowing you to do validate and make UIs from any structured data and then plug in / out your data backend (in memory structs or a real DB, etc.).
Re: What ORMs have taught me: just learn SQL (2014)
#216Each time I see someone complain about ORMs I remember Greenspun's tenth rule[1], which adapted to ORM would be: "Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a decent ORM." ORMs are hard for a reason. Using an ORM doesn't mean you can't or shouldn't use plain SQL where the situation calls for it. You can mix and match perfectly fine. [1] ht…
> ORMs are hard for a reason. Yes, the object-relational impedance mismatch. It's the classic case of having a hammer (OOP) and trying to make everything look like a nail.
[deleted]
Re: What ORMs have taught me: just learn SQL (2014)
#217Earlier quoted context omitted.
ORMs let you drop into SQL whenever you need, usually in a way that is fully compatible with the model, so that's entirely false.
Running raw user SQL isn't a prerequisite of an ORM needed to make it an "ORM", it's a useful feature that most ORMs try to include because the authors recognize the many shortcomings. Also, by writing raw engine-specific SQL, you automatically invalidate one of ORMs biggest selling points which is being SQL-database agnostic. And by "drop into", this typically means writing custom stitching code that stitches the SQ…
> you automatically invalidate one of ORMs biggest selling points which is being SQL-database agnostic
1. If the suggested alternative is writing only SQL from the get-go, then why would one even care about database agnosticism?
2. A large part of SQL is compatible between databases, so this might be a non-issue.
3. You can always use specific in-database abstractions such as Views and Stored Procedures for those complicated bits.
Re: What ORMs have taught me: just learn SQL (2014)
#218In my opinion this whole problem is one of the strongest condemnations of OOP. Even if OOP really were a great way to model your data, to express relationships and property types and such (setting aside all the questionability of that claim), it's all just going to end up in a database anyway . Unless you're using a denormalized database like Mongo, or the bulk of your application state is non-persistent, your perfec…
What makes you think that the DB will always by the dominant data store for a business object?
Business objects need a lot more, from rendering, processing, email sending, notifications, etc.
All those things are well approximated by an object and poorly approximated by SQL.
Re: What ORMs have taught me: just learn SQL (2014)
#219I use a data mapping ORM and I've literally not have any of these concerns. They are all non-issues. The first item about querying is relevant but all ORMs allow you to drop into SQL to execute a complex reporting-style query. It's not really necessary if you are just querying in objects to manipulate (which is what ORMs are good for).
A data mapper is not an ORM, it's a data mapper. It's a different access pattern.
But I do agree that data mappers tend to be better.
Re: What ORMs have taught me: just learn SQL (2014)
#220Earlier quoted context omitted.
> you automatically invalidate one of ORMs biggest selling points which is being SQL-database agnostic. I haven't heard anyone talk seriously about database-agnosticism since the very early 2000s. Maybe some commercial products still try (choose MS or Oracle!), but it's rare nowadays. The primary selling point of an ORM is that it abstracts marshaling/un-marshaling rows to/from entities. Instantiating and persisting…
> I haven't heard anyone talk seriously about database-agnosticism since the very early 2000s. Do you use the same database engine for your unit and integration testing as you do production? I don't. I use sqlite for unit and local integration testing, and aurora-mysql for production. As a side note, I quite literally can't use aurora-mysql for local unit and integration testing. It doesn't exist outside AWS.
> I don't. I use sqlite for unit and local integration testing, and aurora-mysql for production.
That's a recipe for tests that don't catch edge cases.