Safe mechanism for converting strings to existing atoms

[macintux]

Proposed alternative to @seancribbs's #181 (RIAK-1392) that doesn't place existing schemas at risk. Don't allow user input to explode the atom table.

[jadeallenx]

I am leaning more toward #200 than #181 (RIAK-1392) (RIAK-1392) on safety grounds but maybe there's compelling future work that #181 (RIAK-1392) (RIAK-1392) enables I'm missing. Thoughts @seancribbs?

[seancribbs]

Biased opinion: #181 (RIAK-1392) is safer. If you're allowing a user to create atoms via your config file, you're going to have a bad time.

[seancribbs]

Addendum: I don't know any case where #181 (RIAK-1392) would break existing schemas.

[macintux]

Realistically, though, how many atoms can you create in a config file (barring active attempt to break the system)?

I’m in favor of #181 (RIAK-1392) (RIAK-1392) if I can be convinced it’s harmless, just don’t know how to evaluate that risk for schemas we don’t know about.

-John

On Aug 5, 2015, at 3:54 PM, Sean Cribbs [email protected] wrote:

Biased opinion: #181 (RIAK-1392) (RIAK-1392) #181 is safer. If you're allowing a user to create atoms via your config file, you're going to have a bad time.

—
Reply to this email directly or view it on GitHub #200 (comment).

[seancribbs]

It honestly doesn't really matter that much to me; I just don't see how existing_atom gets you any significant benefit. If there are multiple possible values, the schema writer should use enum anyway.