4 ms·

I like the newer Scala frameworks, like Slick (http://slick.typesafe.com/ http://slick.typesafe.com/). They work with tuples rather than classes. Fits much bett

I like the newer Scala frameworks, like Slick (http://slick.typesafe.com/ http://slick.typesafe.com/). They work with tuples rather than classes. Fits much better with the relational model.

stormbrew 13y ago
I am far more interested in this kind of approach to things these days than ORMs or object databases. The relational model is a very powerful way of looking at data and almost all ORMs wind up neutering all of that power, leaving you with the absolute worst of all worlds. What's needed is good (possibly object oriented) interfaces to relational data, which is a very distinct concept from ORM.
- jacques_chester 13y ago
  In my opinion, what's actually needed is to realise that object orientation is a dead end. We need relational programming languages. ORMs can't work for a simple reason. They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation. This remark constitutes 100% of your RDA of cryptic ranting.
  - auvrw 13y ago
    total tangent, but in defense of graphs: it's worth noting that graphs are actually a lot more expressive than they might appear at first glance. it's possible to interpret linear orders, algebraic groups, or any other theory written in finite language with graph theory (according to Marker's book on model theory, which references Hodges' for details on the proof)
    - jacques_chester 13y ago
      Not tangential at all and I while I hate being wrong, I like learning new things. Graphs are very expressive. But most of the time, when you try to express the domain model as a tree (inheritance) it leads to muddiness because most domain models are not truly tree-like. Then we try to express it as graphs (composition), but that gives up the advantages of hierarchy. If you instead express things as sets and subsets, you can enjoy the advantages of both inheritance (DRY logic) and composition (numerous). Some languages kinda sorta have this through mixins or modules. But not quite.
  - mindcrime 13y ago
    ORMs can't work for a simple reason. But they do. They work every freaking day, in millions of applications, all over the world. I think it would be more correct to say "ORM's can't work perfectly for every conceivable scenario involving an RDBMS". But they certainly can, and do, work for many, many use cases. They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation. But if you started with a graph, transform it to the more expressive set world, then transform it back to a graph, why would you lose anything? And in my experience that's usually the way ORM's are used... to persist an object-graph and then query/retrieve parts of that graph. Now if you're taking an existing schema, developed for different usage patterns, and trying to layer on top of it with an ORM, then, yes, you should expect problems. We need relational programming languages. That's an interesting idea. What would such a language look like?
  - dragonwriter 13y ago
    > In my opinion, what's actually needed is to realise that object orientation is a dead end. We need relational programming languages. The second part is true, the first is not. While certain popular OO programming languages and SQL are limited in incompatible ways (creating the so-called "object-relational impedance mismatch", which is more properly the "certain-OO-languages-to-SQL-impedance-mismatch"), there is no inherent mismatch between the OO and relational models, and there is no reason you can't have both in the same language. This is pretty central to Date and Darwen's Third Manifesto [1] and the languages that implement the features it requires of "D" [2]. [1] http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf [2] http://en.wikipedia.org/wiki/D_(data_language_specification) http://en.wikipedia.org/wiki/D_(data_language_specification)
- moron4hire 13y ago
  Actually, that's been the philosophy behind my personal data access system, https://github.com/capnmidnight/SqlSiphon https://github.com/capnmidnight/SqlSiphon It is all just SQL, and the classes it maps to for select statements are really just records, they can only map to raw system types and have no additional functionality. The delete and update statements take no class parameters, they only take raw system types. It's basically meant to have as simple as possible of a way to execute stored procedures, with an added layer of type safety for parameters and a little intellisense help along the way. Essentially, I treat the application-level method name--and its parameter names and types--as repeated information, and attempt to eliminate repetition. The system calls a stored procedure that has the same name as the method, passing parameters that have the same name and type as the method parameters. And that's about it! I've been using a version of this project in production systems for... well... almost 7 years now, and it's been a breeze. The project is a little bit out of date right now. I'm working on rebuilding a new feature that I prototyped poorly 6 months ago but was an incredible boost in productivity. The feature is the ability to manage the stored procedure create/alter statements from within the data layer, at the site of the method calls. It eliminates the last bit of repetitiveness in a database project: the repetition of the names of things in the database versus the application. I had done the same for the table definitions, but that turned out to be a mistake (and thus why I need to rewrite the SP generator system, the two were too closely linked so I just ripped them out completely). I found myself going down that same old road of every ORM, trying to solve graphs of data types, graphs that the database is already pretty capable of solving with a simple join. Because that's the real problem with ORMs: even their developers don't trust the database.
lmm 13y ago
I'm just now moving away from Squeryl (slick was far too immature) to go back to Hibernate. I found the relational approach far too cumbersome, and unpleasant to use if my classes didn't exactly correspond to my database tables.

I like the newer Scala frameworks, like Slick (http://slick.typesafe.com/ http://slick.typesafe.com/). They work with tuples rather than classes. Fits much better with the relational model.

stormbrew 13y ago

I am far more interested in this kind of approach to things these days than ORMs or object databases. The relational model is a very powerful way of looking at data and almost all ORMs wind up neutering all of that power, leaving you with the absolute worst of all worlds. What's needed is good (possibly object oriented) interfaces to relational data, which is a very distinct concept from ORM.

jacques_chester 13y ago
In my opinion, what's actually needed is to realise that object orientation is a dead end. We need relational programming languages. ORMs can't work for a simple reason. They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation. This remark constitutes 100% of your RDA of cryptic ranting.
- auvrw 13y ago
  total tangent, but in defense of graphs: it's worth noting that graphs are actually a lot more expressive than they might appear at first glance. it's possible to interpret linear orders, algebraic groups, or any other theory written in finite language with graph theory (according to Marker's book on model theory, which references Hodges' for details on the proof)
  - jacques_chester 13y ago
    Not tangential at all and I while I hate being wrong, I like learning new things. Graphs are very expressive. But most of the time, when you try to express the domain model as a tree (inheritance) it leads to muddiness because most domain models are not truly tree-like. Then we try to express it as graphs (composition), but that gives up the advantages of hierarchy. If you instead express things as sets and subsets, you can enjoy the advantages of both inheritance (DRY logic) and composition (numerous). Some languages kinda sorta have this through mixins or modules. But not quite.
- mindcrime 13y ago
  ORMs can't work for a simple reason. But they do. They work every freaking day, in millions of applications, all over the world. I think it would be more correct to say "ORM's can't work perfectly for every conceivable scenario involving an RDBMS". But they certainly can, and do, work for many, many use cases. They are trying to map from the world of sets into the world of graphs. Sets are more expressive, so there is always a good chance that there will be a lossy transformation. But if you started with a graph, transform it to the more expressive set world, then transform it back to a graph, why would you lose anything? And in my experience that's usually the way ORM's are used... to persist an object-graph and then query/retrieve parts of that graph. Now if you're taking an existing schema, developed for different usage patterns, and trying to layer on top of it with an ORM, then, yes, you should expect problems. We need relational programming languages. That's an interesting idea. What would such a language look like?
- dragonwriter 13y ago
  > In my opinion, what's actually needed is to realise that object orientation is a dead end. We need relational programming languages. The second part is true, the first is not. While certain popular OO programming languages and SQL are limited in incompatible ways (creating the so-called "object-relational impedance mismatch", which is more properly the "certain-OO-languages-to-SQL-impedance-mismatch"), there is no inherent mismatch between the OO and relational models, and there is no reason you can't have both in the same language. This is pretty central to Date and Darwen's Third Manifesto [1] and the languages that implement the features it requires of "D" [2]. [1] http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-2013-02-07.pdf [2] http://en.wikipedia.org/wiki/D_(data_language_specification) http://en.wikipedia.org/wiki/D_(data_language_specification)
moron4hire 13y ago
Actually, that's been the philosophy behind my personal data access system, https://github.com/capnmidnight/SqlSiphon https://github.com/capnmidnight/SqlSiphon It is all just SQL, and the classes it maps to for select statements are really just records, they can only map to raw system types and have no additional functionality. The delete and update statements take no class parameters, they only take raw system types. It's basically meant to have as simple as possible of a way to execute stored procedures, with an added layer of type safety for parameters and a little intellisense help along the way. Essentially, I treat the application-level method name--and its parameter names and types--as repeated information, and attempt to eliminate repetition. The system calls a stored procedure that has the same name as the method, passing parameters that have the same name and type as the method parameters. And that's about it! I've been using a version of this project in production systems for... well... almost 7 years now, and it's been a breeze. The project is a little bit out of date right now. I'm working on rebuilding a new feature that I prototyped poorly 6 months ago but was an incredible boost in productivity. The feature is the ability to manage the stored procedure create/alter statements from within the data layer, at the site of the method calls. It eliminates the last bit of repetitiveness in a database project: the repetition of the names of things in the database versus the application. I had done the same for the table definitions, but that turned out to be a mistake (and thus why I need to rewrite the SP generator system, the two were too closely linked so I just ripped them out completely). I found myself going down that same old road of every ORM, trying to solve graphs of data types, graphs that the database is already pretty capable of solving with a simple join. Because that's the real problem with ORMs: even their developers don't trust the database.

lmm 13y ago

I'm just now moving away from Squeryl (slick was far too immature) to go back to Hibernate. I found the relational approach far too cumbersome, and unpleasant to use if my classes didn't exactly correspond to my database tables.