Re: Ticket spam

2006-10-25 Thread Michael Radziej 

Adrian Holovaty schrieb:
>> Also, I've been mulling over the idea of requiring an account signup
> in order to post tickets and comments. Would that be worth the pain?

I wouldn't mind to have to sign up before I could submit a 
ticket, but it seems there's no automatic sign-up in trac. That 
would be a nuisance.

I'm especially annoyed by appending spam to a ticket when I'm on 
the Cc and when all the settings get changed. Perhaps it would 
help if one could only create new tickets anonymously but not 
append to them? I haven't seen so many newly created spam tickets 
since Akismet was activated. The mass comes in through adding to 
existing tickets, or is this only my impression=?

But I'd prefer the account signup way combined with automatic 
sign-up (perhaps after email verification).

Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DecimalField

2006-10-25 Thread Michael Radziej 

Jason Davies schrieb:
> Hi,
> 
> I am working on an application which deals with monetary values and it
> *really* needs proper support for decimal, fixed-point (as opposed to
> floating-point) values.
> 
> See: http://code.djangoproject.com/ticket/2365
> 
> Could someone take a look and get this patch approved?
> 
> I think we should just distribute decimal.py to maintain Python 2.3
> compatibility.

Good luck, but I must say I made good experience with just using 
a patched django. I'd only recommend that you keep your patches 
separate somehow (there are plenty of tools for that, just ask 
the list if you need recommendations).

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: asynchronous validation

2006-10-25 Thread Michael Radziej 

Hey Malcolm,

thanks for your help!

Malcolm Tredinnick:
> There is no signal dispatched in the manipulators, so your best bet
> would be to replace the get_validation_errors() method in the
> Manipulator class with your own method that calls the original method
> and then sends off any signal or further processing that you want to do.
> Since custom manipulators sub-class Manipulator, this is easy.

Since this actually happens in 'get_advisories()' (which I 
patched into Manipulator), I changed it there. I finally decided 
to do it the other way around, and do it a bit more generic. 
get_advisories() looks if any validator has a 'prepare' method 
(and calls all prepare()s before calling the the validators).
This way the validator can start the dns query in prepare() and 
in __call__() check the result. Works fine, though it's a very 
special solution.

Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Data for globalization

2006-10-25 Thread GinTon 


James Bennett wrote:
> If you'd be interested in helping to develop useful models for that
> using this data, that'd be great :)
James, I also developed the Django model and a loader.

http://webda.python-hosting.com/browser/trunk/Django/I18n

But now it's necessary that Django developers help with the integration.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

fastcgi: maxRequests

2006-10-25 Thread Michael Radziej 

Hi,

flup provides a way to limit the requests handled by a process, 
but manage.py runfcgi does not allow to set it.

I'm a little bit anxious that there would be a memory hole 
somewhere (though I *was* careful) and would like to set this option.

Would that be a wanted feature? Or was there a reason against it?


Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: fastcgi: maxRequests

2006-10-25 Thread Jacob Kaplan-Moss 

On 10/25/06 9:14 AM, Michael Radziej wrote:
> flup provides a way to limit the requests handled by a process, 
> but manage.py runfcgi does not allow to set it.
> 
> I'm a little bit anxious that there would be a memory hole 
> somewhere (though I *was* careful) and would like to set this option.
> 
> Would that be a wanted feature? Or was there a reason against it?

Yeah, it sounds like a good idea.  I've never found any memory leaks in 
Django, but I still use Apache's MaxClients just in case; it would be nice to 
do the same for fastcgi.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DecimalField

2006-10-25 Thread Jacob Kaplan-Moss 

On 10/24/06 5:25 PM, Jason Davies wrote:
> I think we should just distribute decimal.py to maintain Python 2.3
> compatibility.

I'm +1 on the patch if someone can resolve two things:

* Is the license for decimal.py compatible with Django's BSD license?

* Are the developers of decimal.py (is that the PSF now?) OK with us 
distributing it?

In general, in order to distribute third-party code with Django we need to be 
cleared both legally and morally.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Debugging ticket #2438

2006-10-25 Thread Oliver Lavery 
Hi django folks,The company I work for has been using django for a few
months now, and I have to say it's a fantastic bit of work. Nice to
finally use a web framework with a decent architecture. Thanks!We've been plagued by one issue that is pretty disturbing, though:
http://code.djangoproject.com/ticket/2438I've
spent some time trying to figure out what's going on with this issue.
Models seem to disappear in the admin interface on a production server,
import occasionally works inconsistently, and the more we look into it,
what's breaking seems to get more and more mysterious.
We have an environment where this is 100% repro. Anyone have
any idea what we could do to try to figure what the heck is going on?Cheers,~ol

--~--~-~--~~~---~--~~
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  -~--~~~~--~~--~--~---

Re: Ticket spam

2006-10-25 Thread Christopher Lenz 

Am 25.10.2006 um 11:24 schrieb Michael Radziej:
> Adrian Holovaty schrieb:
>>> Also, I've been mulling over the idea of requiring an account signup
>> in order to post tickets and comments. Would that be worth the pain?
>
> I wouldn't mind to have to sign up before I could submit a
> ticket, but it seems there's no automatic sign-up in trac. That
> would be a nuisance.

Multiple options here, all plugins:

1. 
Allows you to switch to a setup where users can register and get a  
real account. Also provides form-based login.

2. 
Allows people with TICKET_DELETE permissions to delete complete  
tickets, or (more interestingly) revert individual changes to  
tickets. This requires the WebAdmin plugin to be installed.

Also, using the BadContent black-listing more effectively (read:  
update it more frequently) would get rid of a lot of spam I'm seeing  
on Django. I'd recommend giving out more accounts to (trusted) people  
who volunteer doing spam cleanup, allowing them to revert spam  
changes (using the TicketDelete plug) and add stuff to BadContent in  
a more timely manner.

The SpamFilter plugin has optional IP-blacklisting which can help  
reduce many kinds of spam, too. I have no idea whether that's enabled  
on code.djangoproject.com. BTW, is the Akismet filter disabled now?

Hope that helps,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: fastcgi: maxRequests

2006-10-25 Thread Michael Radziej 

Jacob Kaplan-Moss schrieb:
> On 10/25/06 9:14 AM, Michael Radziej wrote:
>> I'm a little bit anxious that there would be a memory hole 
>> somewhere (though I *was* careful) and would like to set this option.
>>
>> Would that be a wanted feature? Or was there a reason against it?
> 
> Yeah, it sounds like a good idea.  I've never found any memory leaks in 
> Django, but I still use Apache's MaxClients just in case; it would be nice to 
> do the same for fastcgi.

Then I'll take it and make a patch. I've already digged into flup 
for that purpose and it's not a big deal.

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Akismet hit - need to be whitelisted

2006-10-25 Thread Michael Radziej 

Hi,

can someone please whitelist me, however this works?

Thanks,

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49 911 9352-0 - Fax +49 911 9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DecimalField

2006-10-25 Thread Jason Davies 

Jacob Kaplan-Moss wrote:
> On 10/24/06 5:25 PM, Jason Davies wrote:
> > I think we should just distribute decimal.py to maintain Python 2.3
> > compatibility.
>
> I'm +1 on the patch if someone can resolve two things:
>
> * Is the license for decimal.py compatible with Django's BSD license?

It's definitely GPL-compatible (see
http://www.python.org/doc/Copyright.html) - but I don't think that
necessarily means it's compatible with Django's license.  I am not a
lawyer :-(

> * Are the developers of decimal.py (is that the PSF now?) OK with us
> distributing it?

I'm not sure how easy it is to get in touch with the developers
themselves.

I don't like the option of falling back to floats in Python 2.3 because
it means an application might not produce exactly the same results as
it would using decimals.

Jason


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Re: DecimalField

2006-10-25 Thread James Bennett 

On 10/25/06, Jason Davies <[EMAIL PROTECTED]> wrote:
> It's definitely GPL-compatible (see
> http://www.python.org/doc/Copyright.html) - but I don't think that
> necessarily means it's compatible with Django's license.  I am not a
> lawyer :-(

Django is BSD-licensed.


-- 
"May the forces of evil become confused on the way to your house."
  -- George Carlin

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Re: DecimalField

2006-10-25 Thread Joseph Kocherhans 

On 10/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 10/24/06 5:25 PM, Jason Davies wrote:
> > I think we should just distribute decimal.py to maintain Python 2.3
> > compatibility.
>
> I'm +1 on the patch if someone can resolve two things:
>
> * Is the license for decimal.py compatible with Django's BSD license?

The file itself doesn't specify a different license, so it's
presumably under the PSF license.

> * Are the developers of decimal.py (is that the PSF now?) OK with us
> distributing it?

Here's the first part of the header from decimal.py in python 2.5. The
authors are listed if anyone wants to contact them.

# Copyright (c) 2004 Python Software Foundation.
# All rights reserved.

# Written by Eric Price 
#and Facundo Batista 
#and Raymond Hettinger 
#and Aahz 
#and Tim Peters

Joseph

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: DecimalField

2006-10-25 Thread Jacob Kaplan-Moss 

On 10/25/06 4:52 PM, Jason Davies wrote:
> It's definitely GPL-compatible (see
> http://www.python.org/doc/Copyright.html) - but I don't think that
> necessarily means it's compatible with Django's license.  I am not a
> lawyer :-(

Nor am I, but figuring out the legality of distributing decimal.py is 
unfortunately something someone we'll have to do.  I don't have time myself to 
read the Python license; does anyone here know if it is BSD-compatible?

> I'm not sure how easy it is to get in touch with the developers
> themselves.

Would the PSF be the right community to ask here?

> I don't like the option of falling back to floats in Python 2.3 because
> it means an application might not produce exactly the same results as
> it would using decimals.

Agreed -- consistency is important.

Jacob

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Debugging ticket #2438

2006-10-25 Thread [EMAIL PROTECTED] 

Oliver Lavery ha scritto:

> We have an environment where this is 100% repro. Anyone have any idea what
> we could do to try to figure what the heck is going on?

Hi,

i've run into the issue myself a few times. Most of the times it was
due to something wrong in the model code (even source formatting if i
remember correctly or use of some model field name or database field
name which doesn't exist -not sure about this one-).

Sometimes it even happened randomly on a per HTTP request basis. 1st
hit it wouldn't show some models, 2nd hit it would.

Lorenzo


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Debugging ticket #2438

2006-10-25 Thread Malcolm Tredinnick 

On Wed, 2006-10-25 at 11:17 -0400, Oliver Lavery wrote:
> Hi django folks,
> 
> The company I work for has been using django for a few months now, and
> I have to say it's a fantastic bit of work. Nice to finally use a web
> framework with a decent architecture. Thanks!
> 
> We've been plagued by one issue that is pretty disturbing, though: 
> 
> http://code.djangoproject.com/ticket/2438
> 
> I've spent some time trying to figure out what's going on with this
> issue. Models seem to disappear in the admin interface on a production
> server, import occasionally works inconsistently, and the more we look
> into it, what's breaking seems to get more and more mysterious. 
> 
> We have an environment where this is 100% repro. Anyone have any idea
> what we could do to try to figure what the heck is going on?

The cause of the problem in the ticket is in the third last comment on
the ticket (the last one by me). You cannot use querysets on models
until all your models are defined, so you cannot use them in choices
attributes, etc.

It is *very* hard to fix this bug at the moment. We need the internal
model cache, or something similar, in order to have reverse relations
(without requiring the developer to annotate both ends of the relation)
and setting that up needs to be done after we know about all the models.
I have a couple of ideas on how we might be able to fix it, but they are
all fairly intrusive (not in a backwards incompatible way, just in a
"lot of work" way) and I have too many other Django things behind
schedule at the moment to be able to work on this yet.

Fortunately, every case that I've seen where somebody wanted to put a
queryset into a model definition has been avoidable by using a function
that returned an iterator instead (thereby deferring the queryset
evaluation) or with other refactorings that moved the value retrieval
elsewhere.

If you aren't doing queryset evaluation (or something similar that
forces Django to populate the model cache) in your model, then you don't
actually have ticket #2438, you have something else and a reproducible
test case would be good.

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
-~--~~~~--~~--~--~---

Re: schema-evolution: status?

2006-10-25 Thread Victor Ng 

Any luck with schema evolution lately?

I'm starting to look at seeing if i can merge this back to trunk as
well, but wanted to know if you've made any progress.

I'm using the postgresql_psycopg2 backend.

vic

On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> postgresql
>
> On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> >
> > which backend are you using?
> >
> > Matthew Flanagan wrote:
> > > Derek,
> > >
> > > I have manually merged the trunk into my local working copy of the
> > > schema-evolution branch and started playing with it. I wanted to
> > > question the SQL "sqlevolve" is outputting. I have this model in an
> > > application called "asset":
> > >
> > > class Interface(models.Model):
> > > name = models.CharField(maxlength=64, core=True, db_index=True,
> > > help_text='The name of the interface as given by the asset.')
> > > interfacetype = models.ForeignKey(InterfaceType)
> > > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > > raw_id_admin=True)
> > > # allow for EUI-48 and EUI-64 addresses
> > > mac_address = models.CharField(maxlength=24, blank=True,
> > > help_text='The EUI-48 or EUI-64 physical address of the 
> > > interface.')
> > > domain = models.CharField(maxlength=255, blank=True,
> > > help_text='The DNS domain this host resides in.')
> > > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > > num_in_admin=10, num_extra_on_change=5)
> > > objects = InterfaceManager()
> > >
> > > def _get_meta(self):
> > > return self._meta
> > > meta = property(_get_meta)
> > >
> > > def __str__(self):
> > > return "%s:%s" % (self.asset, self.name)
> > >
> > > def get_absolute_url(self):
> > > return self.asset.get_absolute_url()
> > >
> > > class Meta:
> > > ordering = ['name']
> > > unique_together = (('asset', 'name'),)
> > >
> > > class Admin:
> > > pass
> > >
> > > and the schema from "./manage.py sql asset":
> > >
> > > CREATE TABLE "asset_interface" (
> > > "id" serial NOT NULL PRIMARY KEY,
> > > "name" varchar(64) NOT NULL,
> > > "interfacetype_id" integer NOT NULL,
> > > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > > "mac_address" varchar(24) NOT NULL,
> > > "domain" varchar(255) NOT NULL,
> > > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > > UNIQUE ("asset_id", "name")
> > > );
> > >
> > >
> > > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > > my models it outputs:
> > >
> > > BEGIN;
> > > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > > UPDATE "asset_interface" SET "name_tmp" = "name";
> > > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > > COMMIT;
> > >
> > >
> > > Any ideas why it is doing this?
> > >
> > > regards
> > >
> > > matthew
> > >
> > > >
> > >
> >
> >
> > >
> >
>
> >
>


-- 
"Never attribute to malice that which can be adequately explained by
stupidity."  - Hanlon's Razor

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: schema-evolution: status?

2006-10-25 Thread Matthew Flanagan 

Vic,

On 26/10/06, Victor Ng <[EMAIL PROTECTED]> wrote:
>
> Any luck with schema evolution lately?
>

I haven't done anything further with it since my last email in this
thread. Nor have I had any response from the developer regarding the
issue I previously highlighted.

Other django users would be more likely to test this branch out if it
were up to date with the latest trunk.

regards

matthew

> I'm starting to look at seeing if i can merge this back to trunk as
> well, but wanted to know if you've made any progress.
>
> I'm using the postgresql_psycopg2 backend.
>
> vic
>
> On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > postgresql
> >
> > On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
> > >
> > > which backend are you using?
> > >
> > > Matthew Flanagan wrote:
> > > > Derek,
> > > >
> > > > I have manually merged the trunk into my local working copy of the
> > > > schema-evolution branch and started playing with it. I wanted to
> > > > question the SQL "sqlevolve" is outputting. I have this model in an
> > > > application called "asset":
> > > >
> > > > class Interface(models.Model):
> > > > name = models.CharField(maxlength=64, core=True, db_index=True,
> > > > help_text='The name of the interface as given by the asset.')
> > > > interfacetype = models.ForeignKey(InterfaceType)
> > > > ipaddress = models.ForeignKey(IPAddress, verbose_name='IP Address',
> > > > raw_id_admin=True)
> > > > # allow for EUI-48 and EUI-64 addresses
> > > > mac_address = models.CharField(maxlength=24, blank=True,
> > > > help_text='The EUI-48 or EUI-64 physical address of the 
> > > > interface.')
> > > > domain = models.CharField(maxlength=255, blank=True,
> > > > help_text='The DNS domain this host resides in.')
> > > > asset = models.ForeignKey(Asset, edit_inline=models.TABULAR,
> > > > num_in_admin=10, num_extra_on_change=5)
> > > > objects = InterfaceManager()
> > > >
> > > > def _get_meta(self):
> > > > return self._meta
> > > > meta = property(_get_meta)
> > > >
> > > > def __str__(self):
> > > > return "%s:%s" % (self.asset, self.name)
> > > >
> > > > def get_absolute_url(self):
> > > > return self.asset.get_absolute_url()
> > > >
> > > > class Meta:
> > > > ordering = ['name']
> > > > unique_together = (('asset', 'name'),)
> > > >
> > > > class Admin:
> > > > pass
> > > >
> > > > and the schema from "./manage.py sql asset":
> > > >
> > > > CREATE TABLE "asset_interface" (
> > > > "id" serial NOT NULL PRIMARY KEY,
> > > > "name" varchar(64) NOT NULL,
> > > > "interfacetype_id" integer NOT NULL,
> > > > "ipaddress_id" integer NOT NULL REFERENCES "ip_ipaddress" ("id"),
> > > > "mac_address" varchar(24) NOT NULL,
> > > > "domain" varchar(255) NOT NULL,
> > > > "asset_id" integer NOT NULL REFERENCES "asset_asset" ("id"),
> > > > UNIQUE ("asset_id", "name")
> > > > );
> > > >
> > > >
> > > > when I run "./manage.py sqlevolve asset" with absolutely no changes to
> > > > my models it outputs:
> > > >
> > > > BEGIN;
> > > > ALTER TABLE "asset_interface" ADD COLUMN "name_tmp" varchar(64);
> > > > UPDATE "asset_interface" SET "name_tmp" = "name";
> > > > ALTER TABLE "asset_interface" DROP COLUMN "name";
> > > > ALTER TABLE "asset_interface" RENAME COLUMN "name_tmp" TO "name";
> > > > ALTER TABLE "asset_interface" ALTER COLUMN "name" SET NOT NULL;
> > > > COMMIT;
> > > >
> > > >
> > > > Any ideas why it is doing this?
> > > >
> > > > regards
> > > >
> > > > matthew
> > > >
> > > > >
> > > >
> > >
> > >
> > > >
> > >
> >
> > >
> >
>
>
> --
> "Never attribute to malice that which can be adequately explained by
> stupidity."  - Hanlon's Razor
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Ticket spam

2006-10-25 Thread Daniel Poelzleithner 

Matthew Flanagan wrote:

> In one project I know of that uses trac they just have a single login
> for users to create tickets and submit patches rather than requiring
> every user to register. This eliminated 99% of their trac spam. They
> just documented the login/password in their 'contributing' docs. This
> saves someone having to manage trac users.

Nice idea. I use the trac Admin UsersManagerSomething Plugin, so users
can easily register an account and then change wiki pages, submit
tickets, etc. I don't use any other spam blocking and spam stopped after
that.

kindly regards
  daniel

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---