- 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.
- Fix formatting on giant postgres query
- Invert the section that looks for unique constraints to look for a
constraint and join to the constraint_column_usage to be more in line
with the mysql query and also it makes a little bit more sense.
- Add more checks to ensure the schema is being enforced in the postgres
side of things as several pieces in the unique checks were missing it
which would lead to false positives.
- Fix#77 for postgres
- Needed a couple nil checks in the eager loading code. The tests didn't
(and now do) cover the case where an eager load function returns
empty or nil things.
- Fix#66
- 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.
- Previously each call to qm.Load would overwrite your eager loading
statement. I think this was deliberate at one point but it's pretty
inconsistent. If we need to overwrite we can call queries.SetLoad()
- The problem with the old approach is that it was looping over each
result, and then recursing in and doing it's loading. But in reality
we should only load from a table in a capacity once (tomany, toone).
Query was not properly joining on both name and schema. This will fix the issue where a constraint exists across multiple schemas and causes duplicate relationships to be created.
- Previously we used a lot of template magic to see if we could
use LastInsertId. But there's a much simpler check that's worth doing,
do this at the table level and then let it fall through.
