One related comment on this is my desire to avoid getters and setters.
For example let's say my_field is the JSON field. I hope we can do this:
my_model = TheModelClass()
my_model.my_field = {'a': 1, 'b': 2} # this is setting with a dict
my_mode.save() # the field contents are now JSON serialized in the DB
Also this:
my_model = TheModelClass.get(pk='12345')
type(my_model.my_field) # This would show dictionary not string
Is that possible with this implementation idea? What do others think
about this?
Thanks for doing this @pcreech!
-Brian
On 08/23/2016 12:16 PM, Michael Hrivnak wrote:
Agreed. It's so simple, let's just make one and use it. Trying to use a
pre-existing one might actually end up being more work.
Michael
On Tue, Aug 23, 2016 at 11:00 AM, Jeff Ortel <[email protected]
<mailto:[email protected]>> wrote:
Given your findings and the simplicity of implementing this, it
seems to make sense. We can always replace it
later if we find something better.
On 08/22/2016 03:08 PM, Patrick Creech wrote:
> While implementing the task models for Pulp 3.0, I came to the
conclusion that we still have a
> requirement for implementing a database field strictly for object
persistence. The best solution
> for this will be to utilize a custom field for this, that allows
us to serialize it to a json string
> and back. The question then became implementing our own or
utilize something that already exists.
>
> Afer searching through a link provided by Sean[0] at what's
available for JSONField implementations,
> I have come to the decision that it will probably be more
beneficial for us to implement our own.
>
> Most implementations seem to stem from this blog post[1] which
(sadly) isn't available at it's
> original location anymore (wayback machine link)
>
> After reading the various implementations (which are in various
states of completeness/abandon for
> the most part), I came to the conclusion that this is actually
something that is simple and common
> to do, and that the various implementations were really only
differing in python and django-agnostic
> coding as compared to functionality.
>
> With that, I feel it's more prudent for us to implement our own
field instead of relying on another
> implementation. This should allow us to be more flexible with
what our requirements are for this
> specific use case and keep it simple.
>
> Before I move forward with this, does anyone else have any
thoughts/concerns?
>
>
>
> [0] https://djangopackages.org/grids/g/json-fields/
<https://djangopackages.org/grids/g/json-fields/>
> [1]
https://web.archive.org/web/20160201155913/http://cramer.io/2009/04/14/cleaning-up-with-json-and
<https://web.archive.org/web/20160201155913/http://cramer.io/2009/04/14/cleaning-up-with-json-and>
> -sql
>
>
>
> _______________________________________________
> Pulp-dev mailing list
> [email protected] <mailto:[email protected]>
> https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
>
_______________________________________________
Pulp-dev mailing list
[email protected] <mailto:[email protected]>
https://www.redhat.com/mailman/listinfo/pulp-dev
<https://www.redhat.com/mailman/listinfo/pulp-dev>
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
_______________________________________________
Pulp-dev mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-dev
