Re: Considering alternate SQL Code generators
> 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
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
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
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
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
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
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
> 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
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
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
[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 -~--~~~~--~~--~--~---
