-
Notifications
You must be signed in to change notification settings - Fork 80
Feature Req: Settings/Mash type #19
Comments
Does the Object type not work for you? |
Hmm, well, my use case is to ensure that the data is JSON-encoded for portability (other systems in other languages want to read the data). Too specific of a use case for dm-types? That and I have an aversion to storing marshaled data and would rather deal with explicitly versioning it (as a general statement about Object-based properties). So, all I really want is a Json field that ensures a Hash and exposes the property as a Mash. |
@solnic what do you think? too specific for dm-types? I'm leaning that way but I wanted to get your input first. |
@nevir actually I think a better idea would be to extend existing Json property rather than adding a new one. |
The more I work with the Json property type, the more I think it's a real mistake that it doesn't use a Mash/HashWithIndifferentAccess. Simply: the property allows you to set keys of symbol (or string) type. Until the property is persisted, you'll even be able to interact with the symbol keys. The moment you persist/reload, that behavior changes. This really doesn't seem to follow the "it behaves how I'd expect" principle, given what it's supposed to represent, nor the "it behaves consistently" principle. Seems like "it should work" would be a far more common case than "it shouldn't work/I'd want it to error out". And, FWIW, preventing symbol keys from being used in the first place would feel pedantically heavy-handed on the positive side, outright retarded on the negative. |
A pattern I frequently use in an internal application is a Json field tweaked so that it stores/retrieves
Mash
es (mainly when storing complex configuration that we don't want to codify into a table)Is this something that would fit into dm-types? (I'm willing to write a patch, or an extra gem if it doesn't fit)
The text was updated successfully, but these errors were encountered: