3 ms·

Generally I use the model builder methods for this anyway, because I'm using the ORM and the models represent tables, so I barely ever build my own select state

Generally I use the model builder methods for this anyway, because I'm using the ORM and the models represent tables, so I barely ever build my own select statements at all. https://laravel.com/docs/8.x/eloquent https://laravel.com/docs/8.x/eloquent

XCSme 5y ago
Even with an ORM, isn't there the risk of typing Flight::select('name') instead of Passenger::select('name'), if both values return the same data type (string)? Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`? Aren't most of those issues found as soon as you first test the feature?
- unfocussed_mike 5y ago
  I don't understand the point you're getting at here. Isn't this kind of typo more or less universally possible? Which code library or generator can protect you from errors like this (and divine your intent?) You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query. Laravel also allows you to express model relationships, so Flight might have: public function passengers(): BelongsTo { return $this->hasMany(Passenger::class); } and then you can do things like: $flight->passengers->where('name', 'like', 'XCSme%'); > Aren't most of those issues found as soon as you first test the feature? I don't know. The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects). And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all). In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful. (The Lighthouse GraphQL binding is where this stuff gets really interesting) At any rate, we're unlikely to agree. [edit: removed a tired-brain word choice mistake!]

XCSme 5y ago

Even with an ORM, isn't there the risk of typing Flight::select('name') instead of Passenger::select('name'), if both values return the same data type (string)? Is that harder to do than accidentally typing `SELECT name FROM flights` instead of `SELECT name FROM passengers`? Aren't most of those issues found as soon as you first test the feature?

unfocussed_mike 5y ago
I don't understand the point you're getting at here. Isn't this kind of typo more or less universally possible? Which code library or generator can protect you from errors like this (and divine your intent?) You can be protected from SQL injection and you can have various other query operations, and you can gain refactoring support (e.g. by telling the models the new table name), or you can add custom scopes that encapsulate transformations on the query. Laravel also allows you to express model relationships, so Flight might have: public function passengers(): BelongsTo { return $this->hasMany(Passenger::class); } and then you can do things like: $flight->passengers->where('name', 'like', 'XCSme%'); > Aren't most of those issues found as soon as you first test the feature? I don't know. The thing is, an ORM brings you other stuff (like a query builder integration) that allows you to construct queries without having to glue SQL strings together (and chain and pass query objects). And Laravel separately also brings you a migration tool that allows you to encapsulate upgrades to your database as code snippets (so you can put code live without manually fiddling with SQL at all). In my experience even really small apps benefit from this at some level. The discipline of using regular patterns like this is really useful. (The Lighthouse GraphQL binding is where this stuff gets really interesting) At any rate, we're unlikely to agree. [edit: removed a tired-brain word choice mistake!]