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.
This commit adds more ways of specifying selects:
-) You can now pass in a []string. This is mostly for convenience,
since you may want to dynamically create a list of fields to be
selected.
-) You can now use variables. This is important because a select
could take user input. For example, finding a MAX between a record
and a given number could be easily done using select, and then
you don't have to process anything in backend logic. This is also
necessary to use postgres text search capabilities (which actaully
play nicely with the rest of gorm).
-) You can now chain select calls. This could be useful in
conjunction with gorm's scopes functionality.
jnfeinstein