Skip to content
This repository has been archived by the owner on Apr 17, 2018. It is now read-only.

Feature Req: Settings/Mash type #19

Open
nevir opened this issue Apr 29, 2011 · 5 comments
Open

Feature Req: Settings/Mash type #19

nevir opened this issue Apr 29, 2011 · 5 comments

Comments

@nevir
Copy link
Contributor

nevir commented Apr 29, 2011

A pattern I frequently use in an internal application is a Json field tweaked so that it stores/retrieves Mashes (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)

@dkubb
Copy link
Member

dkubb commented May 17, 2011

Does the Object type not work for you?

@nevir
Copy link
Contributor Author

nevir commented May 18, 2011

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.

@dkubb
Copy link
Member

dkubb commented May 18, 2011

@solnic what do you think? too specific for dm-types? I'm leaning that way but I wanted to get your input first.

@solnic
Copy link
Contributor

solnic commented May 19, 2011

@nevir actually I think a better idea would be to extend existing Json property rather than adding a new one.

@jpr5
Copy link
Member

jpr5 commented Jun 9, 2011

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants