On 3/2/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> limodou wrote:
> > Django is developing very quickly, so many things to catch up.
> > Has anyone written a change logs let us know the latest changes you.
>
> There are always the auto-generated sort, such as:
>
> http://code.djangoproject.com
limodou wrote:
> Django is developing very quickly, so many things to catch up.
> Has anyone written a change logs let us know the latest changes you.
There are always the auto-generated sort, such as:
http://code.djangoproject.com/timeline/
http://code.djangoproject.com/log/
--
--Max Battcher
On 3/2/06, limodou <[EMAIL PROTECTED]> wrote:
> Django is developing very quickly, so many things to catch up.
> Has anyone written a change logs let us know the latest changes you.
Does the Trac timeline not count? ;)
--
"May the forces of evil become confused on the way to your house."
-- Ge
Django is developing very quickly, so many things to catch up.
Has anyone written a change logs let us know the latest changes you.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~--
Suppose you have a model that looks something like this (on the magic-
removal branch):
class Example(models.Model):
title = models.CharField(maxlength = 50, unique_for_date = 'date')
date = models.DateTimeField(auto_now_add = True)
class Admin:
...
If I try to create an instance
On 3/1/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> I just wanted to say that 'syncdb' is great! You guys rock.
>
> And a big thanks to Georg too for the transaction stuff - I've been
> looking on in admiration over the past few days.
Plenty of awesome improvements are happening! I couldn't be mor
I am playing with a class like this:
class Book(models.Model):
name = models.CharField(maxlength=200)
author = models.ManyToManyField(Person)
def set_author(self, a): self.author = a # is this (having to
define the set_ method) fixed yet?
def __repr__(self):
return self.na
On 3/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The problem is a name clash. When you add the shipping foreign key, an
> accessor is created on Address called 'Address.sale_set' (using the related
> table name). Similarly, when you add billing, an accessor is created on
> Address calle
I just posted patches (trunk and magic) for *Subj*. You can find details
here: http://code.djangoproject.com/ticket/1442. It supersedes tickets
#463, #900, and #1237. The fix was inspired by ticket #1268.
I tested it with MySQL running Python 2.3 and Python 2.4 using simulated
load (http://ope
I have been going through some code this morning and moving it over to
magic-removal. One of my models has a ForeignKey field that is
optionally empty. Before I can attempt to access the value of the
ForeignKey, I first need to check that it exists, so I have a few places
where the code says
On 3/2/06, Kevin <[EMAIL PROTECTED]> wrote:
I'm trying to port my application over to the magic removal branch andran into this problem. My model for a shopping cart requires both ashipping and billing address, so I defined it as follows:class Sale(
models.Model):contact = models.ForeignKey(Co
I'm trying to port my application over to the magic removal branch and
ran into this problem. My model for a shopping cart requires both a
shipping and billing address, so I defined it as follows:
class Sale(models.Model):
contact = models.ForeignKey(ContactInfo)
shipping = models.Foreig
excellent, thanks!
--~--~-~--~~~---~--~~
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 [EM
On Wed, 2006-03-01 at 17:55 -0800, Kevin wrote:
> I had this same problem. I checked through the source code and my
> guess is that the new magic-removal branch requires all models to be in
> a module named .models
>
> Now my existing code was split up between functions and then I just
> used th
I had this same problem. I checked through the source code and my
guess is that the new magic-removal branch requires all models to be in
a module named .models
Now my existing code was split up between functions and then I just
used the __all__ variable to add them together.
__init__.py:
_
On Wed, 2006-03-01 at 22:21 +, xamdam wrote:
> I have a model with a CharField(null=True, default='')
>
> In admin interface the field still appears 'required', whether or not I
> make it visible in field_list
That is correct (and not a bug). If you want to allow empty values (i.e.
the field
Adrian (and anyone else responsible - Jacob?),
I just wanted to say that 'syncdb' is great! You guys rock.
And a big thanks to Georg too for the transaction stuff - I've been
looking on in admiration over the past few days.
Luke
--
"Smoking cures weight problems...eventually..." (Steven Wrig
On 3/1/06, xamdam <[EMAIL PROTECTED]> wrote:
> Using no-magic branch from about a couple of weeks ago.
If possible, update your copy of magic-removal to the latest revision;
there's been a HUGE amount of work done on it recently, and if this is
a bug it may already have been fixed. If you still s
I have a model with a CharField(null=True, default='')
In admin interface the field still appears 'required', whether or not I
make it visible in field_list
I also have a BooleanField(null=True), about which admin does not
complain
interestingly, from manage.py shell, there are no complaints, e
My other changeset developed at this week's Django Sprint is much more
extensive and is best explained by the new section that I am adding to
the DB API docs.
Feedback is welcome.
Rock
Aggregate Functions
===
Aggregate functions perform calculations on columns. Typically
they
I have been sprinting this week with Jacob and others at PyCon.
Here is a small change that I am about to check in that extends the
count() function:
count(self,fieldname="*")
This change in query.py as well as the corresponding funcion in
manager.py extend the count() function. In the default
Nebojša Đorđević wrote:
> When I have models like this:
>
Well, from [2457] in m-r branch django has a transaction support so I suppose
that this question is now irrelevant.
--
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
http://studioquattro.biz/
http://djnesh.blogspot.com/ | http://
Am 28.02.2006 um 21:39 schrieb Jeremy Dunck:
> On 2/28/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>> Actually, PySQLite 2.x does an implicit commit after any DDL
>> statement. I don't think this is enforced at the SQLite level, but
>> supposedly the PySQLite author had reasons to do this in t
> This method also has the advantage that version numbers don't pollute
> your model, but store this in a separate table.
Ignore that bit, you were already suggesting that version numbers are
stored in a separate table, I didn't read it very carefully.
Luke
--~--~-~--~~---
24 matches
Mail list logo
