<FromGitter>
<Blacksmoke16> would be a better experience than automagically defining initializers behind the scene like it does now
<FromGitter>
<Nicolab> surely
<FromGitter>
<Nicolab> I think in this case, the creation of a resource must validate everything. However, the updates are partial. So I have to list each parameter right?
<FromGitter>
<Blacksmoke16> how are you handling it now?
<FromGitter>
<Nicolab> In Go it's about the same. when I do PHP (several years ago lol), same (example with the validator of Laravel)
<FromGitter>
<Blacksmoke16> more so mean on the amber side of things
<FromGitter>
<Nicolab> It's comfortable
<FromGitter>
<Blacksmoke16> like by partial update i assume you are talking about like sending `{"lang":"fr"}` and it just updating that one column
<FromGitter>
<Nicolab> yes
<FromGitter>
<Nicolab> or another
<FromGitter>
<Blacksmoke16> yea how do you handle that?
<FromGitter>
<Nicolab> In Crystal I don't know yet. With the other languages, I simply update as I will with the native driver, except that the ORM (or ODM) or the validator checks the data before
<FromGitter>
<Blacksmoke16> would be easier if you send the whole body representing the user
<FromGitter>
<Nicolab> I think it's an unnecessary constraint
<FromGitter>
<Nicolab> Especially for the backend of a mobile app. In addition it requires larger treatments, just for one or two fields
<FromGitter>
<Blacksmoke16> would basically have to have a way to support setting only xyz fields
<FromGitter>
<Blacksmoke16> since you cant call a setter based on a string value it's tricky
<FromGitter>
<Nicolab> ok
<FromGitter>
<Blacksmoke16> have to be some macro that accepts a field and value and uses a case to set it
<FromGitter>
<Blacksmoke16> one way would maybe adding some `merge` method that accepts `self`
<FromGitter>
<Blacksmoke16> be pretty easy to make it a module and can just include it
<FromGitter>
<Blacksmoke16> `include Mergable` or
<FromGitter>
<Blacksmoke16> naming tbd
<FromGitter>
<Blacksmoke16> esp with that PR, as it would define all the fields as nilable under the hood, so would be able to new one up with just one property set
<FromGitter>
<Blacksmoke16> wouldnt be able to save it ofc tho
<FromGitter>
<Blacksmoke16> how else would you do it?
<FromGitter>
<Blacksmoke16> w/o looking up the record
<FromGitter>
<Nicolab> in crystal I don't know, I've been discovering the echo system for a week
<FromGitter>
<Nicolab> in the end it is a SQL UPDATE query
<FromGitter>
<Blacksmoke16> maybe thats the answer then
<FromGitter>
<Blacksmoke16> define some method that just builds out an update query based on the params
<FromGitter>
<Blacksmoke16> and then execs it
<FromGitter>
<Nicolab> yes I think also
<FromGitter>
<Blacksmoke16> could have it accept `self` as well to keep it more OOP
<FromGitter>
<Nicolab> Yes. I made a lib a long time ago that generated the query. With whitelist of table fields, other fields of the object were ignored
<FromGitter>
<Nicolab> Seeing how much time I waste looking for, I think I would be quicker to do a few things like that (a kind of helper)
<FromGitter>
<Nicolab> It only takes correspondence with the keys we pass to it
<FromGitter>
<Blacksmoke16> would ofc want to run validations on the values before running the update
<FromGitter>
<Blacksmoke16> since its a raw query, nothing preventing you from messing it up
<FromGitter>
<Nicolab> Of course :)
<FromGitter>
<Nicolab> All that's left to do is. Thanks
<FromGitter>
<Blacksmoke16> np
<FromGitter>
<Nicolab> Is it possible to make a raw query with Granite?
<FromGitter>
<Blacksmoke16> Yes
<FromGitter>
<Nicolab> Yea! I searched the code, I can't find