Re: auth_permission column lengths
Hi all, On Tuesday, June 19, 2012 5:12:47 PM UTC+3, Florian Apolloner wrote: > > Hi Greg, > > Django itself can't change that currently since there is no support for > schema alteration in Core. Once we get that we can tackle issues like that > and increase to a sensible limit. (both name and codename might cause > problems…). > > Cheers, > Florian > I have suggested, on the bug itself, a partial solution that requires no database schema change (elide the "name" field if it's too long, as it is only used for display anyway). The "codename" field will then stay problematic, but the limitation there is much less severe. Have fun, Shai. -- 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/-/ly9RVtN53MsJ. 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: Customizable Serialization check-in
> if I put list in input I want list in output, not generator
I wouldn't worry about that. The input and output should be *comparable*,
but it doesn't mean they should be *identical*.
A couple of cases for example:
*) You should be able to pass both lists and generator expressions to a
given serializer, but they'll end up with the same representation - there's
no way to distinguish between the two cases and deserialize accordingly.
*) Assuming you're going to maintain backwards compatibility, model
instances will be deserialized into
django.core.serializer.DeserializedObject instances, rather than
deserializing directly back into complete model instances. These match up
with the original serialized instances, but they are not identical objects.
> deserialized_value function with empty content
Are you asking about how to be able to differentiate between a field that
deserializes to `None`, and a field that doesn't deserialize a value at
all? I'd suggest that the deserialization hook for a field needs to take
eg. the dictionary that the value should be deserialized into, then it can
determine which key to deserialize the field into, or simply 'pass' if it
doesn't deserialize a value.
> I changed python datatype format returned from serializer.serialize
method. Now it is tuple (native, attributes)
I'm not very keen on either this, or on the way that attributes are
represented as fields.
To me this looks like taking the particular requirements of serializing to
xml, and baking them deep into the API, rather than treating them as a
special case, and dealing with them in a more decoupled and extensible way.
For example, I'd rather see an optional method `attributes` on the `Field`
class that returns a dictionary of attributes. You'd then make sure that
when you serialize into the native python datatypes prior to rendering, you
also have some way of passing through the original Field instances to the
renderer in order to provide any additional metadata that might be required
in rendering the basic structure.
Wiring up things this way around lets you support other formats that have
extra information attached to the basic structure of the data. As an
example use-case - In addition to json, yaml and xml, a developer might
also want to be able to serialize to say, a tabular HTML output. In order
to do this they might need to be able attach template_name or widget
information to a field, that'd only be used if rendering to HTML.
It might be that it's a bit late in the day for API changes like that, but
hopefully it at least makes clear why I think that treating XML attributes
as anything other than a special case isn't quite the right thing to do. -
Just my personal opinion of course :)
Regards,
Tom
On Tuesday, 19 June 2012 21:48:37 UTC+1, Piotr Grabowski wrote:
>
> Hi!
>
> This week I wrote simple serialization and deserialization for json format
> so it's possible now to encode objects from and to json:
>
>
> import django.core.serializers as s
>
> class Foo(object):
> ��� def __init__(self):
> ������� self.bar = [Bar(), Bar(), Bar()]
> ������� self.x = "X"
>
> class Bar(object):
> ��� def __init__(self):
> ������� self.six = 6
>
> class MyField2(s.Field):
> ��� def deserialized_value(self, obj, instance,� field_name):
> ������� pass
>
> class MyField(s.Field):
> ��� x = MyField2(label="my_attribute", attribute=True)
>
> ��� def serialized_value(self, obj, field_name):
> ������� return getattr(obj, field_name, "No field like this")
>
> ��� def deserialized_value(self, obj, instance,� field_name):
> ������� pass
>
> class BarSerializer(s.ObjectSerializer):
> ��� class Meta:
> ������� class_name = Bar
>
> class FooSerializer(s.ObjectSerializer):
> ��� my_field=MyField(label="MYFIELD")
> ��� bar = BarSerializer()
> ��� class Meta:
> ������� class_name = Foo
>
>
> foos = [Foo(), Foo(), Foo()]
> ser = s.serialize('json', foos, serializer=FooSerializer, indent=4)
> new_foos = s.deserialize('json', ser, deserializer=FooSerializer)
>
>
> There are cases that I don't like:
>
>- deserialized_value function with empty content - what to do with
>fields that we don't want to deserialize. Should be better way to handle
>this,
>- I put list foos but return generator new_foos, also bar in Foo
>object is generator, not list like in input. Generators are better for
>performance but if I put list in input I want list in output, not
>generator. I don't know what to do with this.
>
>
> Next week I will handle rest of issues that I mentioned in my last week
> check-in and refactor json format (de)serialization - usage of streams and
> proper parameters handling (like indent, etc.)
>
> --
> Piotr Grabowski
>
>
>
>
--
You received this message because you are subscribe
Re: Customizable Serialization check-in
W dniu 20.06.2012 13:50, Tom Christie pisze:
>deserialized_value function with empty content
Are you asking about how to be able to differentiate between a field
that deserializes to `None`, and a field that doesn't deserialize a
value at all?
No :) I had this problem before and I managed to resolve it - default
deserialized_value don't returns anything. It sets the field value.
def deserialized_value(self, obj, instance, field_name):
setattr(instance, field_name, obj)
It is the way I am doing deserialization - pass instance to subfields,
retrieve it from them (should be same instance, but in specific cases
eg. immutable instance, I can imagine that another instance of same
class is returned) and return it.
If I don't declare deserialized_value function then function from base
class is taken. It's expected behavior. So how to say "This field
shouldn't be deserialized". Now I declare:
def deserialized_value(self, obj, instance, field_name):
pass
For true, I can do anything in this function excepting set some value to
instance, but declaring function only to say "do nothing" isn't good
solution for me.
> I changed python datatype format returned from serializer.serialize
method. Now it is tuple (native, attributes)
I'm not very keen on either this, or on the way that attributes are
represented as fields.
To me this looks like taking the particular requirements of
serializing to xml, and baking them deep into the API, rather than
treating them as a special case, and dealing with them in a more
decoupled and extensible way.
For example, I'd rather see an optional method `attributes` on the
`Field` class that returns a dictionary of attributes. You'd then
make sure that when you serialize into the native python datatypes
prior to rendering, you also have some way of passing through the
original Field instances to the renderer in order to provide any
additional metadata that might be required in rendering the basic
structure.
Wiring up things this way around lets you support other formats that
have extra information attached to the basic structure of the data.
As an example use-case - In addition to json, yaml and xml, a
developer might also want to be able to serialize to say, a tabular
HTML output. In order to do this they might need to be able attach
template_name or widget information to a field, that'd only be used if
rendering to HTML.
It might be that it's a bit late in the day for API changes like that,
but hopefully it at least makes clear why I think that treating XML
attributes as anything other than a special case isn't quite the right
thing to do. - Just my personal opinion of course :)
Regards,
Tom
You right that I shouldn't treated attributes so special. I have idea
how to fix this. Where I returned (native, attributes) I will return
(native, metainfo). It's only matter of renaming but metainfo will be
more than attributes. In xml metainfo can contains attributes for field,
in html it can be template_name or widget for rendering. If I don't use
metainfo in my serializer class then it's still universal - can be used
for serialization to any format.
How to create metainfo? Have a method `metainfo' in `Field` class that
returns a dictionary seems to be good idea. And it is for this use-cases
for html. But what to do with xml attributes again? :) They aren't only
field meta informations but they can also contains instance information
valuable in deserialization (like instance pk in current django
solution) so they should be treated as fields, should have access to
instance in serialization and deserialization.
My last thought is that attributes should be treated as normal fields
and be in tuple's native object and in metainfo there will be
information for xml which fields in native should be rendered as attributes.
After first phase:
native =={
'field_1' : value1,
'field_2' : value2,
'field_3' : value3,
}
metainfo == {
'as_attributes' : ['field_2', 'field_3'],
'template_name' : 'my_template'
}
So if we use json in second phase field_2 and field_3 will be render
same way as field_1 because json don't read metainfo. Xml will render
fields according to metainfo['as_attributes']. Html will render native
dict using my_template.
--
Piotr Grabowski
On Tuesday, 19 June 2012 21:48:37 UTC+1, Piotr Grabowski wrote:
Hi!
This week I wrote simple serialization and deserialization for
json format so it's possible now to encode objects from and to json:
import django.core.serializers as s
class Foo(object):
��� def __init__(self):
��� self.bar = [Bar(), Bar(), Bar()]
��� self.x = "X"
class Bar(object):
��� def __init__(self):
��� self.six = 6
class MyField2(s.Field):
��� def deserialized_value(self, obj, instance,� field_name):
��� pass
class MyField(s.Field):
��� x = MyField2(label="my_attribut
