On Sat, Aug 15, 2009 at 10:45:44AM -0700, hcarvalhoalves wrote:
> ForeignKey(..., propagate_on_delete=True)
> CASCADE
>
> ForeignKey(..., propagate_on_delete=False, null=False)
> RESTRICT
>
> ForeignKey(..., propagate_on_delete=False, null=True)
> SET NULL
>
> ForeignKey(..., propagate_on_delet
On Tue, Aug 11, 2009 at 09:50:35AM -0500, Alex Gaynor wrote:
> Right now django-debug-toolbar has a pretty stable panel interface and
> I actually can't recall it changing since release. A possibly more
> interesting issue is that some of the debug information it get's is
> somewhat of a hack, th
On Fri, Sep 16, 2005 at 12:21:08PM -0400, Adrian Holovaty wrote:
> On 9/15/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
> > Then one could put "def gnah" in MODULE_LEVEL instead of
> > "def _module_gnah" in the model, also exceptions and the
> > module_constants that cannot be auto-deduced could
>
On Mon, Sep 05, 2005 at 09:13:11AM -0700, jws wrote:
> There doesn't seem to be anyway to create postgresql tables that use
> inheritance from the Django model syntax. Is that true or am I missing
> something?
I think it's true, but could you explain what you're trying to do? I
can see at least
On Fri, Sep 02, 2005 at 04:19:38PM -, Tim Keating wrote:
> Arguably, making the canonical descriptor of your data structures the
> database (which AFAIK is how Rails does it) has advantages over making
> it the code and building the db from that. However, I don't foresee
> django changing to t
On Thu, Sep 01, 2005 at 10:59:12AM -0500, Brant Harris wrote:
> field in a table needs to be changed. In MySQL it seems to be
> relatively easy to figure it out with DESCRIBE table; harder in
> Postgres; and I believe impossible in SQLite. So there are two ideas
> from there:
I think you've mis
On Thu, Aug 18, 2005 at 11:54:37AM -0500, Jacob Kaplan-Moss wrote:
> Please do me a favor: if you're going to trash Django, be specific.
> Otherwise it sounds like you're just trolling -- which I'm pretty
> sure you're not.
Sorry, I was through this at length some time ago, mostly back when
On Wed, Aug 17, 2005 at 07:52:45PM +, Matthew Marshall wrote:
> this would not be something which a new django user would see, and I think
> that a first 'wow' impression is one of the advantages of this new syntax.
So what I hear you saying is that this is basically a marketing
decision - i
On Wed, Aug 10, 2005 at 11:07:10AM -0500, Jacob Kaplan-Moss wrote:
> The problem with this approach -- which was our first idea, by the
> way -- is that it doesn't handle multiple simultaneous transactions.
> Now, I'm not sure I can coherently articulate an example where this
> would be use
On Tue, Aug 09, 2005 at 06:04:36PM -0500, Jeremy Dunck wrote:
> db.BeginTransaction()
> ...lots of domain code (maybe a graph) doing various stuff, including saves
> db.CommitTransaction();
> Then again, this may be unpythonic here, since explicit = good.
On second thought, +1 for something more
On Tue, Aug 09, 2005 at 04:48:04PM -0500, Adrian Holovaty wrote:
> get_list(), get_object() and delete() all would accept an optional
> cursor keyword argument. If a cursor is explicitly passed in, any/all
> database queries in the function would use that cursor. Otherwise,
Do you see any functio
It's just a little assymetrical, now that you have "pk" magic in the
database API, viz., get_widget(pk=3), that one would still need to
redundantly give the pk's colum name in a ForeignKey if it's not the
(bad, BTW) default "id". I'd thin it would be easy to change the meta
code so that the defa
An FK cycle, at least as described in the ticket, is probably better
modeled as a many-to-many relation. In this case the realtionship
would carry (at least) two binary flags for "owns" and "lives at".
Surely that will have to be extended with a "sends mail to" as soon as
the department of Homela
13 matches
Mail list logo
