dump_as/_class isn't inferring the proper class

[tpitale]

In the case of something like dm-types Csv or anything that essentially results in a String/Text the dm-migration tries to look up the type for that column from a type_map. This happens either by way of looking up the property class itself or by calling dump_class and alias for dump_as. dump_as is an option set on the property (akin to load_as, but that's a class method for the extended type itself).

I'm proposing that dump_as either infers the class that it should dump as (from the property it inherits from maybe, just call super if the option isn't set?) or, at the very least, it does not attempt to use load_as for the dump_as. Given most types are a mapping from something more complex (like an Array) to something simpler, it seems unlikely that load/dump would be the same type.

I'll send a PR if there is one that is preferred. But, if you find this page and you're hitting this problem, start by setting dump_as option on your property using a dm-type.

[tillsc]

I think I already addressed that with my pull request in datamapper/dm-migrations#54 . Maybe you could take a look.

[tpitale]

@tillsc This appears to solve it.

Maybe I was hoping that there could be a dump_as on the custom type just like there is a load_as. Rather than setting it with an option on the property. I guess I'm not sure where the change took place in dm-migrations that broke custom types base type.

[tpitale]

It would be a change for sure to add dump_as, but I like the explicitness of it.

[tillsc]

This never worked for me in any 1.x release. I always had to hack something to get a LOB beneath my JSON/CSV/... complex types.

[tpitale]

Huh, I'm trying to figure out how my custom types worked in the past. Maybe I added the column by hand, rather than through auto upgrade … :shrugs: