3 ms·

Until you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a wee

by dorgo 9y ago

Until you do more than just CRUD. And your ORM's performance drop to zero. And you try to improve performance by circumvent your ORM and get bugs you need a week to debug. Because your ORM has a cache and by cirumventing it you introduced a discrepance between code and database.

pmelendez 9y ago
I do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore
hackits 9y ago
When you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play. I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!
- NiceGuy_Ty 9y ago
  Eh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.
  - hackits 9y ago
    I really don't see this as a major problem. Just have the ability with your compiler to load a external syntax tree for the specific database sql dialect. Then have the ability in the syntax tree to define types that map directly to a type within the language. Easiest approach would just be to resolve the syntax tree to a constant string that is then sent to the database. I don't know why for the vast majority of programming languages they lack a lot of language features that programmer do day in day out eg... text manipulation, xml parsing, json parsing all of which are pretty straight forward and time consuming in languages without multi-line string literals.
TYPE_FASTER 9y ago
So far, I've been happy with SQLAlchemy because of the lack of unexpected behavior. It doesn't cache by default. You can call out to stored procedures, or write raw SQL if you want to.

by dorgo 9y ago

pmelendez 9y ago

I do not know who downvoted but I support this... people don’t believe me but I have seen this exploding in production so many times that is not even interesting anymore

hackits 9y ago

When you have a cache, and even a resultset you're going to get discrepancies between your program state and the database state. If you need to maintain one side over the other that is where locking the records come into play. I find it a bit disappointing in the Java world owned currently by Oracle why the they haven't added extensions to the language so I can write bloody SQL statement and PL/SQL procedures naively in the language!

NiceGuy_Ty 9y ago
Eh, not sold on native sql in a programming language. It doesn't take into account the different styles of databases, let alone the different sql dialects. I think it presents a similar problem as Scala's xml literals, which are now seen as language bloat especially since JSON has become popular.
- hackits 9y ago
  I really don't see this as a major problem. Just have the ability with your compiler to load a external syntax tree for the specific database sql dialect. Then have the ability in the syntax tree to define types that map directly to a type within the language. Easiest approach would just be to resolve the syntax tree to a constant string that is then sent to the database. I don't know why for the vast majority of programming languages they lack a lot of language features that programmer do day in day out eg... text manipulation, xml parsing, json parsing all of which are pretty straight forward and time consuming in languages without multi-line string literals.

TYPE_FASTER 9y ago

So far, I've been happy with SQLAlchemy because of the lack of unexpected behavior. It doesn't cache by default. You can call out to stored procedures, or write raw SQL if you want to.