The result of .Fields() is quite different with and without withRelation.
I assume that if you call it without withRelation, you don't want the
fields that were cached when withRelation was true.
This commit adds support for two settings:
FOREIGNTYPE - A field that is used to store the type of the owner.
POLYMORPHIC - A shortcut to set FOREIGNKEY and FOREIGNTYPE to the same
value suffixed by "Id" and "Type" respectively.
The type is stored as the table name, which I thought might be useful
for other queries.
The biggest gotcha of this commit is that I flipped the definition of
has_one and belongs_to. gorm is very flexible such that it didn't
really care if it was a has_one or belongs_to, and can pretty much
determine it at runtime. For the sake of the error, I had to define
one of them as belongs_to, and I chose the one with the fields as
the belongs_to, like ActiveRecord. The error could probably be
genericized to "gorm cannot determine type", but I think it's nicer
to tell people DONT DO PATTERN XYZ CAUSE IT WONT WORK. Functionally,
it doesn't matter.
It looks like gorm always uses the snake form of a column by
convention, as seen by searching DBName in scope.go. These counts
were erroring out without the ToSnake'd foreign keys.
Further, the code for has_many and has_one becomes the same (which
makes sense), so I combined the two cases.
This commit allows you to pass a string or an existing database
connection as the source for gorm. The dialect is still required
because a) there is no common reference to it as far as i know, and
b) gorm allows the dialect to differ from the driver. So, for the sake
of simplicity, you still have to specity the dialect.
This is useful if you have an existing transaction, but still
want to use gorm to format your queries.
This is dependent on the defintion of DB in pkg database/sql having
the field 'dsn', which is the database source, obtained via reflect.