Store `DoubleEntry::Line#scope` as integer
orien opened this issue · comments
The attribute DoubleEntry::Line#scope is currently stored as a VARCHAR. The use case for this attribute is to link to some business entity. Therefore the column type should be INTEGER; identical to how ActiveRecord IDs are stored.
what if we want to scope it via some other unique identifier? Eg: uuid?
I'll be smug here and note that a UUID is a number. 😛 However, I agree this change makes the design less generic. But I think the tradeoff is worth it. Consider:
- If a domain concept is important enough to be a scope, it'll likely have a DB representation (and an ID).
- DB table joins between the scoped entity and related lines will be optimised as they won't need to cast the scope column and will make use of indexes.
agreed. i was originally going to say "why not username" but point 1 came to mind. Alrighty! im sold!
@orien while you're right that "If a domain concept is important enough to be a scope, it'll likely have a DB representation (and an ID)." how would you tell what table that ID belongs to?
Right now a scope could be "user-31" or "company-31".
I.e. would this change would remove the ability for a scope to be polymorphic?
Would there be a disadvantage to adding a type column and making it truly polymorphic?
@eadz At present the scope type is encapsulated in the account configuration.
https://github.com/envato/double_entry/blob/master/spec/support/accounts.rb#L7
I like this because it adds the constraint of one scope type per account definition. This simplifies the design and meets my use cases.
@jasoncox the major disadvantage would be the increase in complexity. A minor disadvantage would be increased table size. Advantage: increased configurability.
@orien that only applies when using active_record_scope_identifier but :scope can take any proc which returns a string. I have a use case for polymorphic scopes ( e.g. if you had separate Person and Company models but both could be used as a scope for an account ). A string works fine for this, because you can embed the type in the string "company-1", "user-2" but if this was switched to an integer you'd need a type column as well.
@eadz Ouch! It'd be difficult to join on that association!
In general I try to avoid such relationships. Without knowing your domain though, I won't comment further.
I take your point that storing the scope as a string does provide valuable flexibility.