These are chat archives for rails-sqlserver/activerecord-sqlserver-adapter

17th
Feb 2015
Ken Collins
@metaskills
Feb 17 2015 13:35
(morning)
Sean Griffin
@sgrif
Feb 17 2015 15:52
Thoughts on us having a convention for a namespace where DB specific types live?
That's less verbose than ActiveRecord::ConnectionAdapters::PostgresqlAdapter::OID::DateTime?
Though I suppose ActiveRecord::Type::PostgreSQL::DateTime isn't much better, but I'm thinking there could be value in having that convention
Ken Collins
@metaskills
Feb 17 2015 16:25
Oh yea…. I remember that topic.
I like how the Type constant is aliased in Base.
Which means you could go with Type::Integer and then optionally Type::Integer::PostgreSQL maybe too. But that would break the module name convention tho.
Sean Griffin
@sgrif
Feb 17 2015 16:32
Yeah, I was thinking of reversing it rather than nesting under the specific classes
Ken Collins
@metaskills
Feb 17 2015 16:32
Agreed… Type::PostgreSQL::DateTime is better.
You can discover and refeclt better IMO too.
Sean Griffin
@sgrif
Feb 17 2015 16:33
Basically just thinking about it because I closed an issue related to adding support for infinite dates in PG
Because you can add it yourself if you want it and I think returning Float::INFINITY is too confusing for it to be default behavior
But that means I'm indirectly recommending them subclassing the PG date type (assuming they want support for BC dates, otherwise they can just use the generic)
Which means we should probably have those live somewhere reasonable
Sean Griffin
@sgrif
Feb 17 2015 16:58
I'm really glad I was forced to go down this road. I feel so much better now that I have a global instance of a class called AdapterSpecificTypeRegistry, and the logic was complicated enough I had to pull out an AdapterSpecificTypeRegistry::Registration. You know the resulting API will be super clear and easy to understand when the implementation looks like that
<_<
:cry: :gun:
Ken Collins
@metaskills
Feb 17 2015 17:06
OMG!
I sense so much sarcasm.
Sean Griffin
@sgrif
Feb 17 2015 17:06
I'm very subtle. :trollface:
Ken Collins
@metaskills
Feb 17 2015 17:07
FWIW, it never felt complicated to me. But I had yet to use the external API too.
Sean Griffin
@sgrif
Feb 17 2015 17:07
Really mac? You're going to autocorrect my emoji?
Ken Collins
@metaskills
Feb 17 2015 17:07
I’m about sick of autocorrect.
Sean Griffin
@sgrif
Feb 17 2015 17:07
I think the implementation was already too complex when I had to splat through constructor args
But most of the complexity comes from allowing adapters to override
Ken Collins
@metaskills
Feb 17 2015 17:16
Yea, I buy that.
Sean Griffin
@sgrif
Feb 17 2015 17:17
It's fine. I'm just glad I'm getting it out there at least
Ken Collins
@metaskills
Feb 17 2015 17:51
There is something to be said about being your own benevolant dictator of an OS project.
I made FETCH happen without concensus.
Sean Griffin
@sgrif
Feb 17 2015 17:53
Ha
Are you saying I should fork Rails?
Because I don't think that'll work. XD
Ken Collins
@metaskills
Feb 17 2015 18:31
LOL
Sean Griffin
@sgrif
Feb 17 2015 21:07
Random thing that will affect you: Expected API of types is changing. type_cast_from_user -> cast, type_cast_from_database -> deserialize, type_cast_for_database -> serialize. I removed the type_cast helper and just had deserialize call cast by default. cast_value is unchanged.
Should be pretty mechanical. I used sed for most of it in Rails proper
(This is for Rails 5)
Ken Collins
@metaskills
Feb 17 2015 21:13
Noted.
Sean Griffin
@sgrif
Feb 17 2015 21:14
(Sorry, it's an unnecessary pain in the ass. Wasn't my decision)
Ken Collins
@metaskills
Feb 17 2015 23:05
It’s cool. Remember, I get to be excellent in my little OS silos :) even when there is upstream stuff to deal with. I love it.
Signing off for the night.