Hacker News new | comments | show | ask | jobs | submit login

>It does not use ORM nor installs one.

Take a look at [1]. Congratulations, you've written an ORM.

The belief that ORMs are evil is precisely the belief that this sort of code should be repeated everywhere database access is performed. If you have generalized routines for interacting with the database with more comfortable abstractions then string concatenation, you are using an ORM, but possibly a poorly tested, poorly documented homegrown one instead of a generally accepted solution that has more eyes on it. You are what you claim to be above.

Which is not bad, lightweight ORM is awesome. You could also debate terminology that these are not really objects, but the spirit is still pretty similar to activerecord and sqlalchemy.

[1]https://github.com/go-bootstrap/go-bootstrap/blob/master/bla...




> The belief that ORMs are evil is precisely the belief that this sort of code should be repeated everywhere database access is performed. If you have generalized routines for interacting with the database with more comfortable abstractions then string concatenation, you are using an ORM

This is incorrect.

The sqlx library, included in OP, has generalized routines for interacting with the database, but is not an ORM. The squirrel[1] library for Go lets you produce queries without "string concatenation", but is also very much not an ORM.

An ORM is a specific style of library that attempts to map object oriented data patterns to relational concepts. That's why it's called an Object-Relational Mapping. There are good reasons[2] why people find this approach problematic, which aren't down to cargo culting them as "evil" or believing that everyone should repeat data access code in all projects.

[1]http://github.com/lann/squirrel [2]http://en.wikipedia.org/wiki/Object-relational_impedance_mis...


The simple/typical use case of Django's ORM, sqlalchemy, Rails ActiveRecord, etc. is not much more than a native API for composing SQL queries, and the automated mapping of table rows from the RDBMS into native data structures in the application (which happen to be objects because of the language).

When you claim that you are not using an ORM, a reasonable person would take it to mean that you are forgoing the use of query builders and automated mapping from SQL results to application data structures.

So, it may be true that classifying these libraries as ORMs is incorrect, but the "user experience" as a developer between these libraries and typical ORMs appears to be pretty much the same. Or is that unfair?


I have a lot of experience with Django's ORM and I would say that the essential character of these heavier ORMs is missing from the afore mentioned libraries. They can be used in the way you describe, but that's not their typical usage.

AR/Django encourage you to describe your entire schema, _including_ the relationships between tables, as attributes on your model objects. Upon doing this, you get simple and reliable programmatic access to some basic access and storage patterns.

Using this knowledge of your data model, the ORM can now provide you with more advanced tools: it can automatically join across tables (`select_related`), lazily load dependent data[1], generate SQL schema for you, transparently cache queries[2], automatically provide HTML form validators, and even automate database schema migration for you. The more completely you model the system, the more it can do for you.

In these systems, the database is subservient to the model. This is a problem, because the database is reality and the model is a model.

Dropping to "opaque SQL strings" is discouraged, both because it's considered error prone ("You should leave SQL to the professionals! There are lots of eyes on this!") and because there is often no graceful way to integrate custom query code with your model layer; instead, you investigate how to do so within the confines of the ORM. For every case where you can eventually find what you need (`select_related("user__friends__email")`), there are a dozen where you can't.

People start writing things in application code that could be handled easily and more efficiently by the database: aggregations are a classic, since ORMs support is either missing or incredibly complex. As soon as the application becomes non-trivial[3], the problems magnify. They don't do this because they are stupid, or bad developers, they do this because it's what the tools encourage: they encourage simplistic CRUD access and mistrust/suspicion/fear of SQL.

SQLAlchemy is quite different from this, because its primary focus is to model databases, not to provide some kind of declarative object language with its own set of semantics that do not exist in SQL.

Because Go can't do things like meta classes or creating/modifying types at runtime, a lot of this simply isn't there, even though people want it.

Sqlx does like 2 things; it adds named query parameter support, and it marshals rows into structs. Squirrel is just a query builder. The whole philosophy that the database must somehow be modeled and that access to the database is done via that model is absent.

[1] This is especially durable tarmac with which to pave your road to hell.

[2] http://github.com/jmoiron/johnny-cache

[3] This can mean "lots of requests", or "complex schema", or "complex reporting requirements"... all sorts of things.


Most ORM's are evil. sqlachemy being the only one that I can think of that is not evil (assuming you don't use the object mapping feature). I have found time and again that ORM's create unintended consequences in productions. Generation after generation of ORM's I have dealt with always have the same problem the create N+1, bad queries, memory bloat and are horrible to deal with in production. Once almost all the database operations are replaces with hand writing queries the application performance as expected. It is amazing to me that even though experiences engineers who have had ORM failures continue to use them. Some of have found that the cost of ORM is greater than the benefit and prefer simple libraries.


I think the real reason is that if you are using an ORM, then you should have probably used a non-relational database.


And if you look at dal/README.md https://github.com/go-bootstrap/go-bootstrap/tree/master/bla... , they say that they got the "data access layer" defintion from wikipedia http://en.wikipedia.org/wiki/Data_access_layer , and in the last line of the wiki page says:

> Object-Relational Mapping tools provide data layers in this fashion, following the active record model. The ORM/active-record model is popular with web frameworks.

:D


It may be technically true that this DAL is not really on ORM, but saying that the project skeleton does not contain an ORM is misleading at best. It would be simplest to just rework the language to something like, "a lightweight ORM" or "a database access layer like what's found in traditional ORMs" or something.


I don't really see any object-relational mapping there. I see a set of helper functions for writing basic insert/delete/update queries. Calling that an ORM (even a minimal one) is a bit of a stretch.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: