Meh you essentially are re-enumerating it though, every time you access a field. There is an implicit contract being built up by the code written. I don't find that creating types to make this contract explicit takes much time at all, and there are significant benefits. Unfortunately it simply isn't an option in JS (maybe one could with TypeScript).
> I don't find that creating types to make this contract explicit takes much time at all
This depends on the complexity of your schema. In my case, I was dealing with a 230 table legacy application where some of the tables had as many as 70 columns. I was tasked with building an ad-hoc administrative tool for the owners so that they could perform a few specific tasks and periodically review some information in the system.
I wanted to use an ORM because I didn't want to write a bunch of boilerplate SQL to rig up a tedious but relatively simple internal CRUD app. With that in mind, it certainly didn't make sense to enumerate the details of every column when the alternative (raw SQL) also wouldn't require me to do that. Enumerating explicit column information was unnecessary and certainly would have taken me a lot of time.
Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configuration step to the process.
Not only that, he actually already is doing this when he accesses those fields in code implicitly.
He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause).
I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.
> He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause).
haha a string of SQL is not the same thing as a type constrained data structure.
> I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.
Thankfully, the client used a database that is capable of enforcing type constraints automatically, so I didn't have to spend time writing business logic to reiterate what the database already knows and strictly enforces, in a language that can't even enforce type constraints anyway. Re-declaring your column names and types in javascript literally does nothing except waste time. You shouldn't be reading through your application code to understand the schema of your database, especially when you're dealing with hundreds of tables.
