Re: Moving forward with Serialization.

[Tom Christie]

> Do you know Colander?

I do now.  Thanks, that's very similar, and looks well done.

> I personally think that Forms are already the place that should handle 
(de)serialisation. They already serialise to HTML: why should they not be 
able to serialise to other stream types?

Conceptually I agree.  As it happens django-serializers is perfectly 
capable of rendering into HTML forms, I just haven't yet gotten around to 
writing a form renderer, since it was out-of-scope of the fixture 
serialization functionality.

Pragmatically, I'm not convinced it'd work very well.  The existing Forms 
implementation is tightly coupled to form-data input and HTML output, and I 
think trying to address that without breaking backwards compatibility would 
be rather difficult.  It's maybe easy enough to do for flat 
representations, and pk relationships, but extending it to deal with 
nested representations, being able to use a Form as a field on another 
Form, and representing custom relationships would all take some serious 
hacking.  My personal opinion is that whatever benefits you'd gain in 
DRYness, you'd lose in code complexity.  Having said that, if someone was 
able to hack together a Forms-based fixture serialization/deserialization 
implementation that passes the Django test suite, and didn't look too 
kludgy, I'd be perfectly willing to revise my opinion. 

There's also some subtle differences between serializer fields, and 
Django's existing form fields.  Because form fields only handle form input, 
incoming fields can never be null, only blank or not blank.   With other 
representations such as JSON, that's not the case, so for serializer 
fields, the blank=True/False null=True/False style is appropriate, whereas 
for form fields the required=True/False style is appropriate.

I'm also wary of getting bogged down in high level 'wouldn't it be nice 
if...' conversations.  With just a little bit of work, the 
django-serializers implementation could be turned into a pull request 
that'd replace the existing fixture serialization with something much more 
useful and flexible.  What I'm really looking for is some feedback on if 
it'd be worth my time.

Regards,

  Tom


On Wednesday, 29 August 2012 06:27:35 UTC+1, schinckel wrote:
>
> Hi Tom,
>
> I've knocked around ideas of my own (internally, and on #django) related 
> to serialisation: it's something I've had lots to think about, since until 
> recently, most of my django work was in JSON apis.
>
> I personally think that Forms are already the place that should handle 
> (de)serialisation. They already serialise to HTML: why should they not be 
> able to serialise to other stream types?
>
> This is the approach I've started to use for my API generation code. They 
> already have a declarative nature, and then you get all of the form 
> validation on incoming data: a big improvement over how I've done it in the 
> past.
>
> (I've done some work on a form-based API generation framework: 
> https://bitbucket.org/schinckel/django-repose. Whilst this is in use, 
> it's still not really feature complete).
>
> Matt.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Lc0fSSAdz4IJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Oracle backend vs. numbers

[Anssi Kääriäinen]

On 30 elo, 23:24, Shai Berger  wrote:
> Hi Ian, Jacob, Anssi and all,
>
> Thanks for the quick and positive responses.
>
> On Wednesday 29 August 2012, Ian Kelly wrote:
>
> >https://github.com/ikelly/django/commit/086f502a1c2acb9db27531f7df78c...
>
> > Shai, if you would be willing to try this patch, I'd like to hear your
> > results.  Please bear in mind that this is currently only a POC, so it
> > could be buggy -- I've only run it through the basic tests.
>
> This looks very promising, I will try it next week. On a first look, there is
> just one thing about it that I don't like, and it is related to Jacob's
> comments --
>
> On Wed, Aug 29, 2012 at 10:34 AM, Jacob Kaplan-Moss 
> wrote:> I'm generally adverse to introducing more settings -- settings creep
> > is a real problem -- so a couple of alternate ideas you might consider
> > in producing a patch:
>
> > 1. Just pick one correct behavior, probably for each type. My guess
> > would be that ints and floats should get the fast behavior, and
> > decimals the slow-but-correct one. If you're using a decimal field
> > it's because you care about precision, so correctness makes more sense
> > there IMO.
>
> This would definitely be preferrable to a setting, but it doesn't cover all
> cases -- we have some raw queries where expressions are being selected. The
> default number type in this case -- in current code as well as Ian's patch --
> is to return the data as a string and convert it to int or Decimal. Our code,
> which was written against other database systems, tries to use the result in
> arithmetic with floats, and this fails (you can't add Decimals to floats).
>
> I could, of course, prevent the exception by converting the value to float in
> my code, but that feels like the wrong solution -- I know, in my case, that
> float is enough, and I'd much rather tell the backend "give me floats" than 
> have
> it go through float->str->Decimal->float.
>
> > 2. If you must introduce a setting, do it in DATABASES[OPTIONS]
> > instead of a top-level ORACLE_FAST_NUMBERS or whatever.
>
> That is indeed one good option. The alternative I'm considering -- less
> convenient for me, but perhaps more flexible generally -- is, since we're
> dealing with raw SQL anyway, to put some API for this on the cursor; perhaps a
> property, so that setting it would be a no-op on other backends.
>
> As per Anssi's comment, I have no backwards-compatibility requirements with
> respect to cx_Oracle, but we are still running Django 1.3. Trying to call the
> performance improvement a "bugfix" so it can be backported, while changing
> cx_Oracle requirements, would be pushing my luck, right?

1.3 is out of the question as only security fixes go into that
release. Even 1.4 is out because this isn't a bugfix.

Even if this was backported, requiring library upgrades for Django's
minor version updates should be avoided if at all possible. For 1.4 ->
1.5 upgrade it is in my opinion OK.

It should be possible to subclass Django's Oracle backend, override
parts of the backend with the changes that go into 1.5, and use that
in 1.3.

 - Anssi

-- 
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 from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.