Re: Considering alternate SQL Code generators

2008-10-04 Thread Rock


> In any case, you can already do what you want using custom managers. You
> return a custom queryset that generates the query however you like.
> Lifting all that up into Meta doesn't seem necessary to me.
>

Good feedback Malcolm, but I don't understand that last statement. In
the case of partitioned tables for selected models, the model/manager
interaction with the database is unchanged from normal use accept that
there are some optimized options for batch deletion that a manger
class can add. However the main thing that is different in this
particular case is the creation of the tables and the creation of the
indexes. I was not aware that I could handle that with a custom
manager. (The way that I made this work was by creating a custom
version of the sqlreset manage.py command.)

So how do I customize the table creation using the model manager?


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Comment templatetags should be independent of Comment Model

2008-10-04 Thread Malcolm Tredinnick


On Sat, 2008-10-04 at 21:36 -0700, Thejaswi Puthraya wrote:
> Hi,
> I was going through the patch by carljm for #8630 [1] and decided to
> give it a try. I ran into troubles but not with the patch. The reason
> being comment templatetags reference 'is_public' [2] and
> 'is_removed' [3] fields of the Comment Model.
> 
> The idea for comments customization was to push essential fields onto
> BaseCommentAbstractModel and then inherit from this model. This would
> reduce the need to rewrite templatetags but I screwed this while
> sending patches just before the merge into trunk.
> 
> I can think of two solutions to solve the problem. The first one being
> http://dpaste.com/82448/ and the second one (http://dpaste.com/82449/)
> to push the 'is_public' and 'is_removed' fields onto the
> BaseCommentAbstract Model. Both these changes are backward-compatible.

The second approach does introduce an incompatibility. Anybody who has
created a model using that ABC would now have to alter their tables.
It's not part of the guaranteed stable API, so it's not impossible to
change, but does introduce a backwards-incompatible change.

For that reason I would slightly prefer the first approach at the
moment. But I want to think a bit more about what the common fields for
any comment customisations should be. I don't have a clear idea about
that in my head at the moment.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: suggestion for ticket #8618, Many-to-many intermediary with multiple foreign keys

2008-10-04 Thread Malcolm Tredinnick


On Sat, 2008-10-04 at 10:16 -0700, SliceOf314 wrote:
[...]
> How does the following syntax sound?
> 
> If people like it, or have better suggestions, I could write the
> patch.
> 
> vacations = models.ManyToManyField('Location', through=('person,
> 'Vacation','location'), blank=True)
> 
> This should give enough information to specify the exact attribute
> path for the m2m relationship.  If the intermediary table doesn't have
> multiple keys, then the existing syntax should suffice.

My personal preference for that ticket is that the annotation to say
which foreign keys to use should belong on the model for the
intermediate table, not adding to the declaration of the connecting
models. This seems more self-contained. For example, if you add an extra
column to the intermediate model you only have to update that model, not
hunt down and find the connecting models (which you may not necessarily
have permission to alter the code for in any case).

Regards,
Malcolm



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Considering alternate SQL Code generators

2008-10-04 Thread Malcolm Tredinnick


On Sat, 2008-10-04 at 04:51 -0700, Rock wrote:
> I was taking a look at Ticket #3163 which, when incorporated into
> Django, would add a Meta flag to the model which disables SQL code
> generation. It occurred to me that on a conceptual level, this fix is
> wrong. What would be more generally useful is a dictionary of
> alternate SQL code generating plugins. You could then plugin a custom
> SQL generator by name in a given model Meta class. With this approach
> you could create plugins that would create alternate table formats
> such as partitioned tables, or app-specific DB views or such. You
> could also create and use a plugin that generates no SQL at all which
> would handle the use case targeted by the fix to #3163.

That would be overkill as a solution to #3163. A simple flag that
indicates not to call the creation code works well for that ticket.

I don't really like it as a general thing, either, since doing this on a
per-model basis gets really complicated really fast. In terms of
maintainability it feels like it would be much harder to manage than the
existing plan and implementation of having all the SQL generation in one
place.

In any case, you can already do what you want using custom managers. You
return a custom queryset that generates the query however you like.
Lifting all that up into Meta doesn't seem necessary to me.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Comment templatetags should be independent of Comment Model

2008-10-04 Thread Thejaswi Puthraya

Hi,
I was going through the patch by carljm for #8630 [1] and decided to
give it a try. I ran into troubles but not with the patch. The reason
being comment templatetags reference 'is_public' [2] and
'is_removed' [3] fields of the Comment Model.

The idea for comments customization was to push essential fields onto
BaseCommentAbstractModel and then inherit from this model. This would
reduce the need to rewrite templatetags but I screwed this while
sending patches just before the merge into trunk.

I can think of two solutions to solve the problem. The first one being
http://dpaste.com/82448/ and the second one (http://dpaste.com/82449/)
to push the 'is_public' and 'is_removed' fields onto the
BaseCommentAbstract Model. Both these changes are backward-compatible.
I prefer the first method but would love to hear from you.

I have opened a ticket for this at #9303 [4]. Please do post your
thought either here or on this thread.

[1] http://code.djangoproject.com/ticket/8630
[2] 
http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/templatetags/comments.py#L83
[3] 
http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/templatetags/comments.py#L86
[4] http://code.djangoproject.com/ticket/9303

PS: I have made quite a few mistakes and I am really sorry about them
but if you believe I deserve to be spanked, please do ;-)

--
Cheers
Thejaswi Puthraya
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



suggestion for ticket #8618, Many-to-many intermediary with multiple foreign keys

2008-10-04 Thread SliceOf314

Given the example code in the ticket:

from django.db import models

class Person(models.Model):
name = models.CharField(max_length=100)
vacations = models.ManyToManyField('Location', through='Vacation',
blank=True)


class Location(models.Model):
city = models.CharField(max_length=100)
country = models.CharField(max_length=100)

class Vacation(models.Model):
person = models.ForeignKey(Person)
location = models.ForeignKey(Location)
date = models.DateField()
travel_agent = models.ForeignKey(Person,
related_name='booked_vacations')


How does the following syntax sound?

If people like it, or have better suggestions, I could write the
patch.

vacations = models.ManyToManyField('Location', through=('person,
'Vacation','location'), blank=True)

This should give enough information to specify the exact attribute
path for the m2m relationship.  If the intermediary table doesn't have
multiple keys, then the existing syntax should suffice.

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: session backed form wizard

2008-10-04 Thread David Durham, Jr.

I think I'm pretty much done with what I plan to do with this ticket:

   http://code.djangoproject.com/ticket/9200

Unless anyone else has comments or suggestions that could improve its
chances of actually making it into contrib.

Thanks,

Dave

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: dealing with legacy tables without primary key

2008-10-04 Thread Eric

> I would be surprised if it works with Oracle, unless you replace
> IntegerField with CharField(max_length=18).

I made tests only on sqlite (a trac db).
I mean it ''should'' works with Oracle because Oracle support oid's;
but I have made no test. If someone want to ...

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Composite Primary Keys

2008-10-04 Thread David Cramer
What we hope to achieve here is full support within the Django core, as
opposed to specifying some kind of model. The only thing I have left to do
is implement composite fields, but there's still no API for it.

On Sat, Oct 4, 2008 at 12:03 PM, Eric <[EMAIL PROTECTED]> wrote:

>
> Hi,
> i just discover this thread, I am working on this problem; you may
> take a look at
> http://kenai.com/projects/django-trac/pages/LegacyModule
>
> legacy is a module in my "django hacks trac" (or djac) project; it
> aims to deal with
> tables with no primary key or with composite pk. It provides 2
> methods:
>
> - use of oid field (works on sqlite, oracle, postgres <= 8)
> - composite pk (for mysql that provides no oid field)
>
> cheers,
> Eric
> >
>


-- 
David Cramer
Director of Technology
iBegin
http://www.ibegin.com/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Re: Composite Primary Keys

2008-10-04 Thread Eric

Hi,
i just discover this thread, I am working on this problem; you may
take a look at
http://kenai.com/projects/django-trac/pages/LegacyModule

legacy is a module in my "django hacks trac" (or djac) project; it
aims to deal with
tables with no primary key or with composite pk. It provides 2
methods:

- use of oid field (works on sqlite, oracle, postgres <= 8)
- composite pk (for mysql that provides no oid field)

cheers,
Eric
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



Model fields in localflavor

2008-10-04 Thread Andreas Pelme

[This messages is related to
http://groups.google.com/group/django-developers/browse_thread/thread/64e4d42590145347
]

On Jul 27, 11:39 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-07-27 at 16:39 +0200, Andreas Pelme wrote:
> > Hello
>
> > I have started writing a patch for adding Swedish (se) local flavor.
>
> > I looked at the code for other countries, and noticed that they only
> > contains form fields, not model fields.
>
> > Why is that? E.g. a postal code is very likely to be stored in a
> > database. Why not add default model fields (with appropriate
> > formfield(), validate() etc)?
>
> Well, right now, validation at the model field level isn't really
> supported. The old-style validators were only used by oldforms (and
> old-admin) and the new work that Honza Kral is doing isn't finished yet
> (although there'll probably be something done in time for the 1.0-beta.
>
> Even when that's done however, it won't require adding model fields for
> every type of localflavor. That would be overkill. Instead, it will be
> appropriate to add some validators for those particular types (and
> there'll be a fair bit of sharing with existing form validators).
>
> Realise that (a) almost everything is going to be stored in the database
> in a character field anyway, so different explicit Field subclasses
> doesn't add a lot and (b) you often aren't going to want a separate
> field column in the database for each locale. If somebody is entering an
> address, it will usually be stored in the same fields, regardless of
> whether they're entering an address in Sweden, Argentina or Australia.
>
> Regards,
> Malcolm

I finally got a ticket and patch created for the Swedish localflavor:

http://code.djangoproject.com/ticket/9289
http://code.djangoproject.com/attachment/ticket/9289/django_localflavor_se.diff

However, Swedish personal identity numbers are a little tricky, and can
be represented in a couple of different formats.

The appropriate thing would be to save the fields as their "long"
representation MMDD in the database. However, it is really
common to use them formatted as YYMMDD-, which creates some issues
with people older than 100 years. I wont go into more details about how
the numbers works, however, it would be really useful to do something
like this:

Having a model field with appropriate formfield(), that has the methods
long() and short() for outputting the identity number in the different
formats. You most likely want to store the data in the long format, and
mostly you are interested in the short format. It could also have
birth_day() that returns a datetime.date object.

My questions:
1) Would this be a good use case for introducing a model field in
localflavor(.se)?
2) If so, where should the tests live?
3) If not, with just the form field, the long(), short() and birth_day()
functions would still be very useful when dealing with these numbers.
Where should they live then? contrib.localflavor.se.utils?


Cheers
-- 
Andreas Pelme <[EMAIL PROTECTED]>
PGP/GPG key: 1024D/2F6D209F

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---