Lars Kanis
unread,Nov 12, 2014, 4:15:30 PM11/12/14Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to rub...@googlegroups.com
Hi all,
ruby-pg has type cast support in the repository, now. I tried to make it
flexible, fast and convenient at the same time. While the first two
points are realized with the PG::TypeMap* classes and coder objects, I
aimed with the PG::BasicTypeMap* classes at the latter. They should be a
turn key solution to type casting. There is no fixed defined way to do
type casting between PostgreSQL and Ruby, but whenever the given way of
type casting does not fit the users need, he can put the more flexible
base type maps together, instead.
Now the issue: It is difficult to keep backward compatibility for these
classes, when we change any type casts. For example
PG::BasicTypeMapForResults currently delivers hstore values as String
objects like "a"=>"b", since there is no decoder defined for this OID.
In case we add a decoder for this data type to BasicTypeMapForResults in
the next release, we would probably return a Hash objects instead. This
will most likely break any user code that worked with hstore data before.
So which option should we choose:
- Expulse BasicTypeMap* classes from ruby-pg. This will enforce the use
of PG::TypeMap* classes which require explicit definition which data
type should be mapped by which en/decoder.
- Document BasicTypeMap* classes in such a way, that the user should not
use any data types, that are not covered by the current implementation,
if he cares about backward compatibility in the future.
- Add the ability to enable/disable single types covered by the
BasicTypeMap* classes.
--
Kind regards,
Lars