- When we build the update whitelist (when the user doesn't provide one)
we simply say that the whitelist is all columns except pkeys. The
reason we do this is because sqlboiler doesn't support dirty tracking
and if you want to update just a few fields, it's easier to just
explicitly pass a whitelist when you update. However, in the case of
created_at - it's a field that's usually managed by us and so we
should not be updating it unless a user explicitly requests it via the
whitelist. So if the whitelist is empty we prune that column now if it
exists from the auto-created whitelist.
- The user also reported that upsert has the same fate, but the logic is
somewhat different there. It expects that there's a value for
created_at or it assumes that one needs to be created. There's no
more magic we can do around this one unfortunately. Upsert is a
mythical beast that doesn't play as nicely with our model, so users
will just have to be more careful.
- Fix#106
* Replace flag is a "not recommended for use" flag, and is mainly
present to be used with software that is using sqlboiler as a library,
such as abcweb
- The problem here is that due to the nature of the relationship and the
way the loop was set up it was possible to miss some relationships:
A _ C
\_ D
B _ E
\_ F
Since we looped over A and B and did a break when we found something to
attach it to (in this example A would find C) it would break. What we
should be looping through is CDEF and finding a home for each one.
Did the same change in to_one though it doesn't matter since it's
one-to-one.
to-many is untouched because it's already looping over CDEF and finding
a home for it because the relationship is reversed.
- Fix#98
- This feature remains undocumented because it's not a good idea in most
cases but it enables us to replace a template. This is especially
useful when using sqlboiler as a library since testmain
problematically loads config in it's own magical way, divorced from
even the way sqlboiler in "normal" mode loads it. This enables
replacement of that mechanism by replacing it's template.
- Postgres doesn't care about names for uniqueness of keys unlike mysql
because internally it keeps "oid" values to keep track of everything.
Unfortunately this means that the information_schema standard is
inadequate to differentiate between constraints that are named the
same (which isn't possible in mysql, but is in pg). Hence we have to
dip into the pg specific schemas for better or worse.
- Fix naming of the sample schema in the README since it would fail for
mysql due to duplicate naming.
- Mark test schema up so we don't fix the bad names so we catch
regressions here.
- Fix#85
