<FromGitter>
<kvirani> Hi everyone. I just started using Crystal and Amber for the first time. Loving it so far, esp coming from a Rails background. So before I ask my first question I just want to say a big thank you to the maintainers and contributors of this awesome web framework!
<FromGitter>
<kvirani> Ah so *regarding Q1* looks like it *is* mentioned on the page I linked above, but just under examples. And only as singular (`col:reference`). `references` also works (nice!). But ideally there should a list of what's supported.
<FromGitter>
<Blacksmoke16> @kvirani Granite supports editing the FK on your associations, but wont create them when doing a migration
_whitelogger has joined #amber
<FromGitter>
<kvirani> Thanks @Blacksmoke16 when you saying *editing the FK on your associations* do you mean changing the column name? I was specifically referring to fkey constraints and if Granite will be okay with those constraints in place? I recall AR not being able to handle fkey constraints at the beginning, like versions 1 and 2. Can't recall when they were officially able to handle them but it took a while.
<FromGitter>
<Blacksmoke16> yea granite would throw an exception if you have a constraint and try to save a record that does not fulfill the constraint
<FromGitter>
<Blacksmoke16> but would be throwing it at the DB level, wouldnt be caught at the model level, unless you check for corresponding records first. i think there is a like "exists" validator
<FromGitter>
<kvirani> Awesome, yes db level is fine, I believe AR does the same (without model-level validation in place). I think the issue was more to do with "order of operations" in AR would assume no Fkey and actually do things like updates/deletes/inserts to fkey relationships in the *wrong order*, causing DB-level errors not caused directly by the app developer.
<FromGitter>
<kvirani> Anyway, glad to know that it's a non-issue in Granite. Thanks!
<FromGitter>
<Blacksmoke16> yea shouldnt be
<FromGitter>
<Blacksmoke16> np
<FromGitter>
<kvirani> Just logged an issue #1085 and am wondering what Amber's ideal/idiomatic way is to handle the situation where these form params are empty, but the `params.validation` shouldn't be throwing an error here b/c the fields are indeed present (just just happen to contain empty values)?
<FromGitter>
<kvirani> Did more digging and realized that imho this is an issue. I've submitted a PR #1087 as a quick fix for future generated controllers and it also describes a potentially better but backwards-incompatible fix as an alternative (or additional) fix for the long term. Curious to get thoughts from the maintainers.