5 ms·

>I'm not sure object oriented programming ever really caught on. Uh they have. They were the dominant paradigm for a long time. You haven't been around long en

>I'm not sure object oriented programming ever really caught on. Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new. >Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures? Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified. You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default. >Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code. This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth. Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality. >String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory. Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept. I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.

randomdata 4y ago
> They were the dominant paradigm for a long time. You haven't been around long enough. I've only been programming for about 30 years, so yes still quite young, but during that time the C++/Java style object model has been king, and while it is based on objects, they are definitely not oriented. For orientation you need, at very least, message passing. When was oriented programming popular and not just a cool novelty that rises up from time to time? > Doesn't seem like a relation. Seems like you're referring to a single table with no relationship to other tables specified. A table is represented by a relation[1], yes. A relation isn't a join. A relation is a set of tuples, by literal definition. Does your confusion here stem from not being familiar with the relational model? > String manipulation is what an orm does for you. What string manipulation is required in the ORM phase? You must be thinking of query building, but that's a completely different level of abstraction. Many ORM toolkits also bundle query builders, but you could create an ORM toolkit that expects one to write SQL by hand. They are not intrinsically linked. In fact, most ORM toolkits, even those which come with query builders, do allow you to write SQL by hand if you prefer. [1] Ignoring the peculiarities of SQL which deviate from the mathematically pure model.
- fckgnad 4y ago
  If you've been programming for 30 years, it doesn't show. I'm sorry. This is what a relation is: https://www.techopedia.com/definition/21677/relation https://www.techopedia.com/definition/21677/relation in the context of relational databases. I think you're confused. >What string manipulation is required in the ORM phase? You're just on some strange pedantic purity bent as the other person commented. Even the op refers to his "query builder" as an "orm". Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder. Despite all this it's fairly obvious you know what we mean and what we are trying to say. You're just playing a part here.
  - randomdata 4y ago
    > This is what a relation is: https://www.techopedia.com/definition/21677/relation https://www.techopedia.com/definition/21677/relation "Relation is sometimes used to refer to a table in a relational database" – True, but a relation is any set of tuples. Joining multiple tables together also produces a relation. It's not just tables. It's the more abstract concept of rows and columns, basically. But, as noted earlier, SQL actually deviates from the relational model here. It doesn't actually operate on sets. This is where you find a lot of the gotchas it is famous for. Something like QUEL, which Postgres used instead of SQL for the first 10 years of its life, is closer to Codd's original model. It actually has relations. I expect that deviation is why we're having trouble communicating here. As SQL isn't actually relational, calling them relations is technically a misnomer. While I appreciate the purity bent you say you're off on, I have indicated multiple times that I use relation with acknowledgement of SQL's deviation from the term in its purest sense. Yes, again, SQL relations aren't truly relations, but for the sake of ORM they serve the same purpose. > Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder. Such as? All of the ORMs with query builders I'm familiar with are like "You an use our query DSL and you can even write raw SQL!". They present a clear separation between the ORM and the query building phases. If they were tightly coupled in those toolkits, they wouldn't be able to enable you to use raw SQL queries.

randomdata 4y ago

> They were the dominant paradigm for a long time. You haven't been around long enough. I've only been programming for about 30 years, so yes still quite young, but during that time the C++/Java style object model has been king, and while it is based on objects, they are definitely not oriented. For orientation you need, at very least, message passing. When was oriented programming popular and not just a cool novelty that rises up from time to time? > Doesn't seem like a relation. Seems like you're referring to a single table with no relationship to other tables specified. A table is represented by a relation[1], yes. A relation isn't a join. A relation is a set of tuples, by literal definition. Does your confusion here stem from not being familiar with the relational model? > String manipulation is what an orm does for you. What string manipulation is required in the ORM phase? You must be thinking of query building, but that's a completely different level of abstraction. Many ORM toolkits also bundle query builders, but you could create an ORM toolkit that expects one to write SQL by hand. They are not intrinsically linked. In fact, most ORM toolkits, even those which come with query builders, do allow you to write SQL by hand if you prefer. [1] Ignoring the peculiarities of SQL which deviate from the mathematically pure model.

fckgnad 4y ago
If you've been programming for 30 years, it doesn't show. I'm sorry. This is what a relation is: https://www.techopedia.com/definition/21677/relation https://www.techopedia.com/definition/21677/relation in the context of relational databases. I think you're confused. >What string manipulation is required in the ORM phase? You're just on some strange pedantic purity bent as the other person commented. Even the op refers to his "query builder" as an "orm". Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder. Despite all this it's fairly obvious you know what we mean and what we are trying to say. You're just playing a part here.
- randomdata 4y ago
  > This is what a relation is: https://www.techopedia.com/definition/21677/relation https://www.techopedia.com/definition/21677/relation "Relation is sometimes used to refer to a table in a relational database" – True, but a relation is any set of tuples. Joining multiple tables together also produces a relation. It's not just tables. It's the more abstract concept of rows and columns, basically. But, as noted earlier, SQL actually deviates from the relational model here. It doesn't actually operate on sets. This is where you find a lot of the gotchas it is famous for. Something like QUEL, which Postgres used instead of SQL for the first 10 years of its life, is closer to Codd's original model. It actually has relations. I expect that deviation is why we're having trouble communicating here. As SQL isn't actually relational, calling them relations is technically a misnomer. While I appreciate the purity bent you say you're off on, I have indicated multiple times that I use relation with acknowledgement of SQL's deviation from the term in its purest sense. Yes, again, SQL relations aren't truly relations, but for the sake of ORM they serve the same purpose. > Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder. Such as? All of the ORMs with query builders I'm familiar with are like "You an use our query DSL and you can even write raw SQL!". They present a clear separation between the ORM and the query building phases. If they were tightly coupled in those toolkits, they wouldn't be able to enable you to use raw SQL queries.