Based on this comment, I'm guessing you haven't actually used objection. The main design goal of objection is to NOT restrict flexibility or limit access to DB features.
It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I have to admit I have not; the last time I had to search for a new data access framework for Node was a matter of days before you released 0.1.0 :) I did at least do the bare minimum of reading your documentation and looking at examples to see how it addressed the fundamental weaknesses of object-relational mapping before I mentioned it, though!
I consider models inherently limiting. To be completely fair to Objection, a minimally functional model is maybe half a dozen lines long, and patch takes care of one of the major restrictions of the active record pattern, but recapitulating your database architecture before you can use it necessarily adds a structural rigidity (if badly done, it can be outright brittle) and a certain inertia. This isn't something that can be laid at your or anyone else's doorstep; it's the price of working with record graphs in application code, as implicit in the object-relational mapper pattern. You can argue that it is or can be worth it, but that doesn't mean you don't have to pay it.
First of all, objection is built on knex and every possible operation you can start with it return a query builder that you can modify in any way. You are always 100% in control of what SQL gets executed. There's absolutely no restricting "common-denominator" API. With objection you can always do everything you can do with a query builder, but also a lot of other things. Objection's API is a superset of SQL instead of common-denominator.
Your other point was that models are limiting. Let's test that theory. Let's say you have this model in objection
How is that any different from using a query builder? Instead of mentioning the name of the table in the query, you use the model. The table name and the model class reference are just as easy to change.
Let's say the name of the table changes. All you need to do is to change the tableName property. What if the columns names change? You change the queries, just like you would with a query builder. What if you want to change the model name? Well, search and replace the model name. How about relations? Again, change the model. If you use a plain query builder, you need to update the foreign keys in million places instead.
Using objection's models adds no overhead on top of using a query builder whatsoever. If anything, it removes a great deal of it.
I really don't see what you mean here. You still seem to be talking about your experiences with other ORMs.
Based on this comment, I'm guessing you haven't actually used objection. The main design goal of objection is to NOT restrict flexibility or limit access to DB features.
I have to admit I have not; the last time I had to search for a new data access framework for Node was a matter of days before you released 0.1.0 :) I did at least do the bare minimum of reading your documentation and looking at examples to see how it addressed the fundamental weaknesses of object-relational mapping before I mentioned it, though!
I consider models inherently limiting. To be completely fair to Objection, a minimally functional model is maybe half a dozen lines long, and
patchtakes care of one of the major restrictions of the active record pattern, but recapitulating your database architecture before you can use it necessarily adds a structural rigidity (if badly done, it can be outright brittle) and a certain inertia. This isn't something that can be laid at your or anyone else's doorstep; it's the price of working with record graphs in application code, as implicit in the object-relational mapper pattern. You can argue that it is or can be worth it, but that doesn't mean you don't have to pay it.First of all, objection is built on knex and every possible operation you can start with it return a query builder that you can modify in any way. You are always 100% in control of what SQL gets executed. There's absolutely no restricting "common-denominator" API. With objection you can always do everything you can do with a query builder, but also a lot of other things. Objection's API is a superset of SQL instead of common-denominator.
Your other point was that models are limiting. Let's test that theory. Let's say you have this model in objection
Then you have a bunch of queries all over your database
How is that any different from using a query builder? Instead of mentioning the name of the table in the query, you use the model. The table name and the model class reference are just as easy to change.
Let's say the name of the table changes. All you need to do is to change the
tableNameproperty. What if the columns names change? You change the queries, just like you would with a query builder. What if you want to change the model name? Well, search and replace the model name. How about relations? Again, change the model. If you use a plain query builder, you need to update the foreign keys in million places instead.Using objection's models adds no overhead on top of using a query builder whatsoever. If anything, it removes a great deal of it.
I really don't see what you mean here. You still seem to be talking about your experiences with other ORMs.
I have to say that Objection.js has by far the best docs that I've ever seen so far. Good job!