i'm reading other post on this forum
django use pickle to store non relational data with session...
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe
it was just an idea, Russel... maybe too hard to accomplish in the
right way.
i can use json field in my trunk and that's good for me.
i thought maybe, with validators, django could be be able to
accomplish some of the features of a non relational data store,
without messing up with low lowel dat
django could archive to manage non-relational data on relational db.
i don't want to use a non relational db, because i need foreign key
and i need non relational data.
read the couchdb guide, i think that you can find inspiration to
create powerful things.
i think that some ability of non relati
that is just a proposition, i know that if you need a non relation db
the best thing to do is to have a non relational data store.
but you need a relational data store only if you need to query non
relational data, in the other cases you can use a relational db,
because relational db got foreign k
Hi, guys,
I agree that we should use the right tool for the job; But even a
relational database can be used for semi-structured data when it's not
going to be directly queried. Matter of fact, there's even a design
pattern recognized for that:
http://martinfowler.com/eaaCatalog/serializedLOB.html
On Mon, Nov 7, 2011 at 11:48 PM, Torsten Bronger
wrote:
>
> While I appreciate that Django core is supposed to enforce good
> design practices, one must be careful with that if some practice may
> have valid use cases. You cannot prevent the user from shooting in
> the foot anyway.
>
> While we m
On Mon, Nov 7, 2011 at 9:58 PM, Ric wrote:
> django should be able to handle this kind of situation, and please
> don't be arrogant.
Hi, I'm sorry you felt that I was being arrogant - I don't know the
situations of your project, it may well be exactly what is needed in
that situation.
I was only
Hallöchen!
Tom Evans writes:
> On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote:
>
>> this is my proposition to have custom data inside a model field
>>
>> a json data field, the code is simple as this, and it works with
>> lastest django release
>
> The problem with something like this is that it is r
On Tue, Nov 8, 2011 at 5:58 AM, Ric wrote:
> you say "is rarely a good idea", and that it is the only thing true.
>
> when, like my app, you need to handle document, real documents (like
> invoice, ddt, quotations) and other stuffs, it's a good practice to
> keep all in one table, separating only
you say "is rarely a good idea", and that it is the only thing true.
when, like my app, you need to handle document, real documents (like
invoice, ddt, quotations) and other stuffs, it's a good practice to
keep all in one table, separating only the things that you need to
query, and leave a non re
On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote:
> this is my proposition to have custom data inside a model field
>
> a json data field, the code is simple as this, and it works with
> lastest django release
>
The problem with something like this is that it is rarely a good idea
to stick opaque data
it's a good code.
you wrote:
# TODO: Look for date/time/datetime objects within the structure?
and there is no need, because it's handled by djangojsonencoder
On 7 Nov, 07:06, schinckel wrote:
> I'm doing just this in several cases: I packaged up a JSONField into a
> re-usable
> application:htt
I'm doing just this in several cases: I packaged up a JSONField into a
re-usable
application: https://bitbucket.org/schinckel/django-jsonfield/overview
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web vis
i'm posting this comment into the ticket.
On 6 Nov, 20:14, Ric wrote:
> i'm watching the ticket right now.
> maybe there is no need to to create a class
> JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
> already.
> then it would be great to implement a lazy translation objec
i'm watching the ticket right now.
maybe there is no need to to create a class
JSONDateEncoder(json.JSONEncoder) because there is DjangoJSONEncoder
already.
then it would be great to implement a lazy translation object for
DjangoJSONEncoder to store ugettext_lazy objects.
for me there is no need t
On Sat, Nov 5, 2011 at 7:48 PM, Ric wrote:
> this is my proposition to have custom data inside a model field
>
> a json data field, the code is simple as this, and it works with
> lastest django release
See #12990 -- this is a ticket that has requested exactly this feature.
You'll also see that
16 matches
Mail list logo
