PG::BasicTypeMap - request for comment

107 views
Skip to first unread message

Lars Kanis

unread,
Nov 12, 2014, 4:15:30 PM11/12/14
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



Cody Cutrer

unread,
Nov 13, 2014, 11:31:34 AM11/13/14
to rub...@googlegroups.com
Lars,

I vote for a combination of two and three. Document that in the future additional types may support type casting, so be prepared. Default new type casts to on, and allow them to be individually disabled.

Cody Cutrer




--
You received this message because you are subscribed to the Google Groups "ruby-pg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruby-pg+u...@googlegroups.com.
To post to this group, send email to rub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-pg/5463CDE9.9070100%40greiz-reinsdorf.de.
For more options, visit https://groups.google.com/d/optout.

Jeremy Evans

unread,
Nov 13, 2014, 11:48:49 AM11/13/14
to rub...@googlegroups.com, la...@greiz-reinsdorf.de
On Wednesday, November 12, 2014 1:15:30 PM UTC-8, Lars Kanis wrote:
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.

As long as PG::TypeMapAllStrings remains the default unless the user specifies a type map, I think any of these options is fine, as long as it is documented.

Thanks,
Jeremy
Reply all
Reply to author
Forward
0 new messages