Hi,
In my model I have the field:
created_by = meta.ForeignKey(
User,
verbose_name='created by',
editable=False,
blank=True,
null=True
)
and the module method below to create a "validated" object:
def _module_create(address, prefix, descrip
On 1/9/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/8/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Here's a status update on moving dango.contib.core/auth into django.contirb:
> >>
> > * Remove Package model (and dependencies on it)
> > Ian Holsman still uses this. I'm things we
On 1/8/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Here's a status update on moving dango.contib.core/auth into django.contirb:
>
> * Move sessions from core to django.contrib.sessions (and change dependencies)
> Done.
>
> * Move sites from core to django.contrib.sites (and change dependenc
On 1/9/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> Well, how about this.
>
> >From a user (and ease-of-entry) standpoint the simplest possible
> syntax would be
>
> from django import *
A vehement "no" to this. I strongly, strongly dislike the ambiguity of
"import *" statements. Plus, there
Well, how about this.
>From a user (and ease-of-entry) standpoint the simplest possible
syntax would be
from django import *
I don't know about most of you, but I'm already importing pretty much
all of Django anyway, so I'm not sure this is as expensive as it
sounds. With this approach, yo
>Any thoughts of putting this into the bin or maintenance subdir of Django
>distro?
There is one in the bin directory, only that script has an additional
dependency on the user registrations and so won't run right away,
because only ellington users will have that table.
bye, Georg
> Just a simple cronjob with an SQL statement that blows away outdatedsessions.Any thoughts of putting this into the bin or maintenance subdir of Django distro?Radek
On 1/9/06, hugo <[EMAIL PROTECTED]> wrote:
>True. The fun thing about the recipe is that it produces keys that are>so unique that the
>True. The fun thing about the recipe is that it produces keys that are
>so unique that they do not need to be checked against a db. That's
>where the performance benefit comes from. And I think not checking
>against a db is the "other context" mentioned in the ticket.
Actually it doesn't. It dep
On Jan 9, 2006, at 7:24 AM, Russell Keith-Magee wrote:
Any objections to me cleaning up these methods and removing the
kwargs?
Sounds like a good idea - go for it.
Jacob
Hi all,
I wanted to feel out opinion about two small, but theoretically
backwards-incompatible changes:
1) The DB query get_in_bulk() must be provided with an ID list. This
list can be provided _either_ as the first input argument, or in the
'id_list' kwarg (but not both). I would suggest the k
> Actually the GUID.generate() is more complex than the current version.
True. The fun thing about the recipe is that it produces keys that are
so unique that they do not need to be checked against a db. That's
where the performance benefit comes from. And I think not checking
against a db is the
>session_key = md5.new(GUID.generate() + SECRET_KEY).hexdigest()
>Benefit: unique session key without the need to access the database,
>really fast (more than 20.000 session key per second)
>Drawback: Additional third party dependency.
It's not faster than the current version - it does the same
12 matches
Mail list logo
