- In the bowels of the eager loading we weave in and out of reflection,
but we should not care about using XSlice unless it's going back to
the user. This change makes it so the XSlice is only used where it
matters, everywhere else is *[]*X to avoid type assertion errors from
being able to have either or come into the Load() functions.
- Fix#124
- 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
- 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
- Postgres's behavior when there is no update is that there is an
ErrNoRows thrown back, which we can safely ignore since the only time
this can happen in postgres's case is under this circumstance since
there's no race unlike the mysql upsert code.
- Fix#84
- This is a bug that manifests itself a bunch with our update code where
you cannot actually use the update method to update a key since it
uses the values on the struct to both update the values and find the
object to update but in this operation the key must have two different
values.
- Make postgres name its enums
- Add way to filter columns by whether or not they're an enum
- Split parsing of enums into name & values
- Add strmangle check functions: IsEnumNormal, ShouldTitleCaseEnum
- Add new strmangle enum functions to template test
- Implement a set type called "once" inside the templates so that we can
ensure certain things only generate one time via some unique name.
