Re: GSoC: Customizable Serialization

2010-03-29 Thread Russell Keith-Magee 
On Mon, Mar 29, 2010 at 10:00 PM, gombiuda JHL  wrote:
> Hi all. My name is Gombiuda Jiang. I want to apply the `Customizable
> serialization` project. Here is my proposal. Thanks for your reading and
> commenting.
> As far as I can understand the project, its aim is to make serialization can
> be used out of fixture loading. For example, once we can customize our
> serialization for our models, we can use this built-in functions inside
> `django.core.serialization` instead of writing non-reusable `__unicode__`
> methods.
> With this aim, formats for serialization is necessary because of different
> requirements for different projects. I was shocked when thinking of this,
> because requirements are unlimited. But soon I got the key point: the core
> of this problem is the format customizable, fields selectable, and nested
> fields' serialize-recursion control. Everything got cleared.
> So APIs would maybe like this:
> # inside the model definition
> @serializable(
>     config = (
>                   ((Model_X, Model_Y), ('field_a', 'field_b',
> 'field_fk1_follow', 'field_fk2', 'field_m2m'), {'model_start':'{',
> 'model_end':'}', 'field_start':'name', 'field_end':'', 'separator':','}),
>                   ((Model_P, Model_Q), ('field_a', 'field_b',
> 'field_fk1_follow', 'field_fk2', 'field_m2m'), {'model_start':'[',
> 'model_end':']', 'field_start':'name', 'field_end':'', 'separator':','})
>                   # .
>                   )
> Class Model_A(models.Model):
>     # ..
> Class CustomizeSerializer(serializers.Serializer):
>     def start_serialize(self):
>         # .
>     def end_serialize(self):
>         # ..
>     def start_field(self):
>         # .
>     def end_field(self):
>         # ..
>     def serialize(self):
>         # ..
> The decorator seems ugly, but if possible, the config can be put into the
> meta options of the Model.

"Ugly" is one way to put it. Completely bass-ackwards wrong would be
another. :-)

I can see two major flaws with your suggesion of using a decorator
(or, for that matter, a meta declaration):

 - You're attempting to cram a complex serialization declaration into
the argument list for a decorator (or a single line in a Meta).
Serialization is a complex process. There are many things to declare
and define, and many things to potentially customize. This isn't
something you can declare with a simple argument list.

 - There's no reason serialization should be bound to the model class.
There isn't single clear and correct way to serialize a given model.
Django's fixture loader needs one format. If you use two AJAX
libraries, they each may need a different format. If you have some
back-office system you need to integrate with, it may have another
format. The serialization format needs to be independent of the model
definition.

> Feel free to figure out my faults. Thank you.

It's difficult to comment beyond the feedback I've already given. For
example - you've given an example of a serialization format
declaration, but you haven't given an example of how that declaration
would look when used (i.e., what serialized output would that
declaration provide?).

You also haven't given much detail on the Serializer class itself. The
"start_field/end_field" type interface you've defined as an extension
of Serializer looks like you're just overriding the existing base
class -- I'm afraid I don't see how this improves or simplifies the
process from what is already possible. I'm not saying you don't have a
good idea here - just that you haven't explained your idea in
sufficient detail for anyone to evaluate it in a meaningful way.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Ticket #13184 (SubfieldBase and form validation). Seeking guidance

2010-03-29 Thread Mark L. 
Hello,

I am terribly sorry to have brought this up here, but I would like to
direct some of your attention to the ticket #13184 (http://
code.djangoproject.com/ticket/13184). In a nutshell, you can not raise
ValidationError in the to_python method of a custom model field if
that field has __metaclass__ = models.SubfieldBase (and, quite
frankly, that's something you would like to do, usually), - doing so
breaks form validation (the ValidationError is not caught and
propagates beyond is_valid method of the form instance).

So that means, that either you have *working* form validation, or you
have automatic database-type<->python-type conversion for your custom
model fields, not both at the same time. Which is not all that
terrible, but the documentation never actually mentions this, which
leads me to think, that this is not the way it is supposed to be.

Now, to the actual purpose of this message, - I am more than willing
to take a stab at this issue, only I am not quite sure how exactly it
should be solved. The reply in the tracker mentions three possible
ways to fix this: a fix for the documentation, that will possibly
mention the fact, that you have to provide custom form logic in order
for SubfieldBase to work, two others being the suggestions to alter
the existing form logic slightly (I like this idea more, to be
honest).

It would be really great if someone, who is in in charge (sort of),
could provide at least a little insight on the preferred way of
solving this, so that it can be fixed before 1.2 release.

I would like to mention, that the ticket has a runnable, minimal (-
ish) test case attached, that illustrates the problem, in my opinion,
quite clearly.

With apologies,
Mark

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

GSoC: Customizable Serialization

2010-03-29 Thread gombiuda JHL 
Hi all. My name is Gombiuda Jiang. And firstly I have to apologize for my
mistake of sending a wrong version of the proposal.
I want to apply the `Customizable serialization` project. Here is my
proposal. Thanks for your reading and commenting.

As far as I can understand the project, its aim is to make serialization can
be used out of fixture loading. For example, once we can customize our
serialization for our models, we can use this built-in functions inside
`django.core.serialization` instead of writing non-reusable `__unicode__`
methods.

With this aim, formats for serialization is necessary because of different
requirements for different projects. I was shocked when thinking of this,
because requirements are unlimited. But soon I got the key point: the core
of this problem is the format customizable, fields selectable, and nested
fields' serialize-recursion control. Everything got cleared.

So APIs would maybe like this:
# inside the model definition
Class Model_A(models.Model):
# ..
class Meta:
serializer_config = (
((Model_X, Model_Y), ('field_a', 'field_fk1_follow',
'field_fk2', 'field_m2m'), {'model_start':'{', 'model_end':'}',
'field_start':'name', 'field_end':'', 'separator':','}),
((Model_P, Model_Q), ('field_a', 'field_b', 'field_fk2',
'field_m2m'), {'model_start':'[', 'model_end':']', 'field_start':'name',
'field_end':'', 'separator':';'}),
# .
)

Class CustomizeSerializer(serializers.base.Serializer):
def start_serialize(self):
# .
def end_serialize(self):
# ..
def start_object(self, obj):
# .
def end_object(self, obj):
# ..
def handle_field(self, obj, field):
# ..
def handle_fk_field(self, obj, field):
# ..
def handle_m2m_field(self, obj, field):
# ..
def serialize(self, obj, parent_list):
# ..

End users can customize what they want in serialization on formatting,
fields selection, foreign key/many2many key following if they correctly
pass-in the configuration.

As an immature plan above, I need comments to improve it. Feel free to
figure out the faults. Thank you.
-- 
Sincerely,
江海龙
Gombiuda Jiang

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

GSoC: Customizable Serialization

2010-03-29 Thread gombiuda JHL 
Hi all. My name is Gombiuda Jiang. I want to apply the `Customizable
serialization` project. Here is my proposal. Thanks for your reading and
commenting.

As far as I can understand the project, its aim is to make serialization can
be used out of fixture loading. For example, once we can customize our
serialization for our models, we can use this built-in functions inside
`django.core.serialization` instead of writing non-reusable `__unicode__`
methods.

With this aim, formats for serialization is necessary because of different
requirements for different projects. I was shocked when thinking of this,
because requirements are unlimited. But soon I got the key point: the core
of this problem is the format customizable, fields selectable, and nested
fields' serialize-recursion control. Everything got cleared.

So APIs would maybe like this:
# inside the model definition
@serializable(
config = (
  ((Model_X, Model_Y), ('field_a', 'field_b',
'field_fk1_follow', 'field_fk2', 'field_m2m'), {'model_start':'{',
'model_end':'}', 'field_start':'name', 'field_end':'', 'separator':','}),
  ((Model_P, Model_Q), ('field_a', 'field_b',
'field_fk1_follow', 'field_fk2', 'field_m2m'), {'model_start':'[',
'model_end':']', 'field_start':'name', 'field_end':'', 'separator':','})
  # .
  )
Class Model_A(models.Model):
# ..

Class CustomizeSerializer(serializers.Serializer):
def start_serialize(self):
# .
def end_serialize(self):
# ..
def start_field(self):
# .
def end_field(self):
# ..
def serialize(self):
# ..

The decorator seems ugly, but if possible, the config can be put into the
meta options of the Model.

Feel free to figure out my faults. Thank you.
-- 
Sincerely,
Gombiuda Jiang

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

ibm_db_django now supports Django-1.2

2010-03-29 Thread Rahul 
IBM_DB_DJANGO-0.2.0
---
IBM_DB_DJANGO adaptor enables access to IBM databases from Django
applications http://www.djangoproject.com/. The adaptor is developed
and maintained by IBM.

What's New?

 - Added support for Django-1.2
 - Backward compatibility - Same codebase works with Django 1.0.x,
1.1.x and 1.2
 - Exact look-up for LOB fields upto 4k Chars of data
 - added tablespace_sql method in operations.DatabaseOperations

SVN access to the source
---
http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/

Installation

$ easy_install ibm_db_django

Feedback/Suggestions/Issues

You can provide us feedback/suggestions, or report a bug/defect, or
ask for help by using any of the following channels:
1. Mailing us at open...@us.ibm.com
2. Opening a new issue at http://code.google.com/p/ibm-db/issues/list.
3. By opening new discussion at http://groups.google.co.in/group/ibm_db.
For prerequisites, installation steps and help details, visit -
http://code.google.com/p/ibm-db/wiki/ibm_db_django_README
Try this out and let us know you valuable feedback.

Thanks,
Rahul Priyadarshi

Get Started with DB2 Express-C 9.7.1

DB2 9.7 is now available. Download Express-C for free, go to:
https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=swg-db2expressc_CMP=ECDDWW01_TACT=ACDB206

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.