Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for storage of primitives such as lists and dicts #11

Open
Widdershin opened this issue Apr 27, 2014 · 5 comments
Open

Add support for storage of primitives such as lists and dicts #11

Widdershin opened this issue Apr 27, 2014 · 5 comments
Milestone

Comments

@Widdershin
Copy link
Collaborator

Can be achieved by storing repr of data and using ast.literal_eval to parse.

@gthole
Copy link

gthole commented Aug 8, 2014

Perhaps a formal serializer/deserializer instead of ast.literal_eval? Literally evaluating opens the door for a number of evaluation bugaboos.

If there's support for typed fields, one such field could be a JSONField that could store any dict/list serializable to JSON, which is guaranteed safe.

@Widdershin
Copy link
Collaborator Author

Yeah, further thinking on this has lead me to the same conclusion. Typed fields seem like the way to go. Right now I'm not even sure if the types of ints/strings are preserved.

@gthole
Copy link

gthole commented Aug 9, 2014

Not sure what you mean by "preserved", but if the field classes implement serialize and deserialize methods, it doesn't matter so much what GoogleDocs does. Perhaps looking vaguely like:

class DateTimeField(BaseField):
    def format(self, value):
        return value.isoformat()

    def parse(self, value):
         return datetime.datetime.strptime(value, "%Y-%m-%dT%H:%M:%S.%f%Z")


class IntField(BaseField):
    def format(self, value):
        return str(value)

    def parse(self, value):
        return int(value)

Of course, there should be validation/exception handling etc, and there's the chance that someone could directly (on the web or otherwise) modify the value of a typed column cell to something incorrect and butterDB should handle that gracefully.

@Widdershin
Copy link
Collaborator Author

Definitely thinking along the same lines here. I will probably include this as part of the rewrite.

@Widdershin Widdershin added this to the Rewrite milestone Aug 10, 2014
@gthole
Copy link

gthole commented Aug 11, 2014

I don't want to belabor this point, but a further advantage of typed fields like this would be a fairly direct path for ForeignKey fields (corresponding to row numbers, preferably expressed as spreadsheet formula names).

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

No branches or pull requests

2 participants