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/ > [1] > https://web.archive.org/web/20160201155913/http://cramer.io/2009/04/14/cleaning-up-with-json-and > -sql > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
