Jose, thanks for discarding my concerns! 🙂 Now I see it was just my ignorance of Ecto.

Hi Timur!

> When I need to deserialize some HTTP form data into a Python data structure, I use colander

This would be equivalent to Ecto Changeset. You would define the initial data, the types, and the changeset takes care of validating the input, casting parameters, and give you the parsed and validated data afterwards.

> When I need something like Ecto’s insert_all/3, I use SQLAlchemy core API to define a table object, build an insert query with it and then execute the query providing a list of data structures.

For talking to the database, you use the Ecto repository and queries. Our insert expects a key-value data-structure in contrast to building an insert query and providing a list of parameters. You are free to map, filter and modify the data in any way before giving it to “insert_all”.

> Also, type/2 seems like duplicating type specification by spreading it all over the code instead of defining in one place, the schema.

You only need to use type/2 if you are building a query without a schema (i.e. without specifying the types). If you provide a schema then you don’t need to repeat this information.

> Now I see that Ecto tries to combine input deserialization/validation with data source access layer which goes against my instincts.

The idea of this blog post is to show exactly this is not the case. If you define an Ecto schema, as mentioned above, then you can use the same schema (i.e. the same type information) for both input deserialization and data source layers but there is nothing in Ecto forcing you to do it. If you want to break it apart and first deserialize the data using certain schema and then convert the data into something else that you insert into the data store, using a different schema or using just pure Elixir data, you are free to do so.

Now is my turn: where did I miss the point? 🙂

When I need to deserialize some HTTP form data into a Python data structure, I use colander, a library which doesn’t have anything to do with database, to define a schema, declaratively or imperatively, which takes care of type conversion and validation. The same colander schema may be used to serialize a data structure back into HTTP form.

When I need something like Ecto’s insert_all/3, I use SQLAlchemy core API to define a table object, build an insert query with it and then execute the query providing a list of data structures. SQLAlchemy takes care of type conversion and I don’t have to use anything like type/2 because table definition already contains column types and I’ll just use the same standard Python datetime objects that I got after deserialization.

If I want an object-oriented domain model, I use SQLAlchemy ORM which is build on top of SQLAlchemy core and allows me to map my objects to tables.

Now I see that Ecto tries to combine input deserialization/validation with data source access layer which goes against my instincts.

Also, type/2 seems like duplicating type specification by spreading it all over the code instead of defining in one place, the schema. After all the data source already knows the type and even if it’s schemaless we may still enforce it at the data access library level if we really want.

Where am I missing the point?

solved it by modifying my select to:
“`
select: map(r, [:field1, :field2])
“`