Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hand-coding and maintaining bog-standard glue logic at the start of a project isn't good either. Auto-generation of database and glue logic for your app is possible, and the task usually falls to an ORM. The problem as described is that the glue logic is trying to hide the implementation, making it hard to remake the code when it becomes clear that the out-of-the-box implementation is not appropriate.

This doesn't seem like an insoluble problem; rather than use an ORM to generate an impenetrable glue layer, it would be better to use code generation tools to create a clean database model and a glue layer that can be easily overloaded as required.

What tools exist that give you ORM-esque generation at the start of your project, but allow you to do maintenance on the glue layer later in the project?



  > This doesn't seem like an insoluble problem; rather than use an ORM to generate an impenetrable glue layer, it would be better to use code generation tools to create a clean database model and a glue layer that can be easily overloaded as required.
Glad you brought that up. I too thought about this as a middle ground solution between "boring your self to death by writing dozens of SQL queries and hand mapping to your model" and "black box ORM that generates crazy SQL queries".

I'm not sure it would work though. One of the problems I see is inherent with code generation approach: what happens when you had to modify the generated code and then changed your meta-model and want to regenerate the model again ?

Besides, the problem of "fitting square pigs in a round hole" would remain: SQL is much more versatile and flexible than objects/structs: you simply can't just work with the a table=an object abstraction, which tends to yield inefficient database queries and/or headaches from the developers side. Example:

    update table set one_field=value where some_condition_on_another_field.
How would you expect an ORM to generate a "dense" query like this with it's simplistic view of things ?

The same applies for the select queries, especially for reporting and data aggregation needs, where you would select some columns from multiple tables, possibly with formulas and computed columns.


> SQL is much more versatile and flexible than objects/structs

SQL isn't even turing complete. How can it be more versatile and flexible than your programming language of choice?

> How would you expect an ORM to generate a "dense" query like this with it's simplistic view of things ?

In SQLAlchemy,

    cls.query.filter(<some_condition_on_another_field>).update(dict(one_field=value))




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: