11 ms·

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilatio

> you're being a human compiler. The transformation from "type instance in my language" to "relational data in my storage engine" is absolutely not "compilation". It's a subtle translation of data and grammar, and as the type relationships grow more complex, ORMs fail. The lesson of ActiveRecord, from the perspective of Go, is that ORMs are fundamentally broken abstractions.

gnaritas 13y ago
Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?
- chc 13y ago
  Well, Martin Fowler has gone on the record saying that Active Record (the design pattern, of which Ruby's ActiveRecord is one implementation) is not well-suited to sophisticated data models, and he tends to prefer the Data Mapper pattern — which similar to what's being described for Go.
  - camus2 13y ago
    expect it is quite hard to write a generic data mapper in go as well. something like Hibernate or Doctrine ORM would be nearly impossible to write with go.i'm not talking about the basic features but advanced features of both frameworks.
    - chc 13y ago
      That is true, but genericity is actually not an inherent attribute of Data Mapper. The key idea is that there are fundamental incompatibilities between two data models (e.g. a structure in your program and a relation in your database), and the translation between the two models is a reified component of the program rather than just being absorbed into the behavior of the object itself as in Active Record. There are some efforts along these lines, such as gorp (https://github.com/coopernurse/gorp https://github.com/coopernurse/gorp), but I don't think they're all that widely used.
  - gnaritas 13y ago
    That's not what the OP said, he said the lesson was "that ORMs are fundamentally broken abstractions". Fowler does not believe this, and even if he did, his opinion is certainly not a global lesson as if it were now best practice to consider ORMs fundamentally broken.
- Jweb_Guru 13y ago
  I do, for one, but don't take my word for it... lots of very intelligent people have problems with ORMs. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute... presents a good summary of the problems involved (forgive the inflammatory title). Despite its many problems, SQL remains the best way of interacting with a relational database.
  - gnaritas 13y ago
    > lots of very intelligent people have problems with ORMs. And lots of very intelligent people like them. Both statements are meaningless appeals to authority. > Despite its many problems, SQL remains the best way of interacting with a relational database. That's your opinion, it's certainly not a fact, and just as many disagree as would agree. Secondly, ORM's don't stop you from using SQL where it's beneficial, so ruling out the ORM because you don't like it for some cases is throwing out the baby with the bath water. For standard CRUD operations, ORM's are the best approach by far. Your hand written CRUD operations gain you nothing but extra work.
    - sagichmal 13y ago
      > Your hand written CRUD operations gain you nothing but > extra work. And maintainability. (shrug)
      - Groostav 13y ago
        So, getting fairly seriously tangential, what would you recommend for green field devs? Have you tried to skirt the ORM problem entirely and simply go for object stores / NoSQL?
        parasubvert 13y ago
        Learning direct SQL would be preferable to doing ORM or NoSQL for a greenfield dev, if the problems they're solving involve managing "transactional" data (like sales / orders). It's a great fallback skill to have and if you're ever going to use an ORM in anger you'll need to know SQL well anyway. If they're mostly managing technical data (like clickstreams or logstreams), then, use whatever store makes sense. SQL will be around for decades to come and at least gives one hope they'll learn something about the relational model which is our only logically grounded approach to managing data integrity. NoSQL is appropriate when dealing with problems where (a) have a different natural requirement than general-purpose logical data management, e.g. your problem maps neatly into a log store, document store, search index, flat file, or K/V store and there's no gain in decomposing these structures into relations (b) no one is going to want to query this data or update these things arbitrarily (famous last words); (c) require massive scale and continuous availability and thus don't fit with most of today's SQL databases. ... though you'd still be probably better off looking around Github for the various frameworks to help you manage a sharded/replicated MySQL or PostgreSQL setup before jumping into NoSQL.
camus2 13y ago
that's not the issue here, wether a pattern is good or not is irrelevant.The question is ,is it possible to write something like ActiveRecord and keep its most advanced features in Go. Right now the lack of genericity in the language makes it a no go.

gnaritas 13y ago

Don't be pedantic, my point was clear and you obviously understood it. As for the lessons of active record, says who?

chc 13y ago
Well, Martin Fowler has gone on the record saying that Active Record (the design pattern, of which Ruby's ActiveRecord is one implementation) is not well-suited to sophisticated data models, and he tends to prefer the Data Mapper pattern — which similar to what's being described for Go.
- camus2 13y ago
  expect it is quite hard to write a generic data mapper in go as well. something like Hibernate or Doctrine ORM would be nearly impossible to write with go.i'm not talking about the basic features but advanced features of both frameworks.
  - chc 13y ago
    That is true, but genericity is actually not an inherent attribute of Data Mapper. The key idea is that there are fundamental incompatibilities between two data models (e.g. a structure in your program and a relation in your database), and the translation between the two models is a reified component of the program rather than just being absorbed into the behavior of the object itself as in Active Record. There are some efforts along these lines, such as gorp (https://github.com/coopernurse/gorp https://github.com/coopernurse/gorp), but I don't think they're all that widely used.
- gnaritas 13y ago
  That's not what the OP said, he said the lesson was "that ORMs are fundamentally broken abstractions". Fowler does not believe this, and even if he did, his opinion is certainly not a global lesson as if it were now best practice to consider ORMs fundamentally broken.
Jweb_Guru 13y ago
I do, for one, but don't take my word for it... lots of very intelligent people have problems with ORMs. http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute... presents a good summary of the problems involved (forgive the inflammatory title). Despite its many problems, SQL remains the best way of interacting with a relational database.
- gnaritas 13y ago
  > lots of very intelligent people have problems with ORMs. And lots of very intelligent people like them. Both statements are meaningless appeals to authority. > Despite its many problems, SQL remains the best way of interacting with a relational database. That's your opinion, it's certainly not a fact, and just as many disagree as would agree. Secondly, ORM's don't stop you from using SQL where it's beneficial, so ruling out the ORM because you don't like it for some cases is throwing out the baby with the bath water. For standard CRUD operations, ORM's are the best approach by far. Your hand written CRUD operations gain you nothing but extra work.
  - sagichmal 13y ago
    > Your hand written CRUD operations gain you nothing but > extra work. And maintainability. (shrug)
    - Groostav 13y ago
      So, getting fairly seriously tangential, what would you recommend for green field devs? Have you tried to skirt the ORM problem entirely and simply go for object stores / NoSQL?
      - parasubvert 13y ago
        Learning direct SQL would be preferable to doing ORM or NoSQL for a greenfield dev, if the problems they're solving involve managing "transactional" data (like sales / orders). It's a great fallback skill to have and if you're ever going to use an ORM in anger you'll need to know SQL well anyway. If they're mostly managing technical data (like clickstreams or logstreams), then, use whatever store makes sense. SQL will be around for decades to come and at least gives one hope they'll learn something about the relational model which is our only logically grounded approach to managing data integrity. NoSQL is appropriate when dealing with problems where (a) have a different natural requirement than general-purpose logical data management, e.g. your problem maps neatly into a log store, document store, search index, flat file, or K/V store and there's no gain in decomposing these structures into relations (b) no one is going to want to query this data or update these things arbitrarily (famous last words); (c) require massive scale and continuous availability and thus don't fit with most of today's SQL databases. ... though you'd still be probably better off looking around Github for the various frameworks to help you manage a sharded/replicated MySQL or PostgreSQL setup before jumping into NoSQL.

camus2 13y ago

that's not the issue here, wether a pattern is good or not is irrelevant.The question is ,is it possible to write something like ActiveRecord and keep its most advanced features in Go. Right now the lack of genericity in the language makes it a no go.