On 6/22/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2006-06-21 at 13:35 -0700, Tyson Tate wrote:
> What are the use cases for this sort of construction?
>
Here's another use case: you want to add fields to your table that
don't have a representation in the Django model.
For exa
If you really want an "empty" model -- but with a primary key, you
could define an "auto" field and delcare it to be the primary key. This
would give you in the DB the exact same thing as an empty model would.
One use case is implementing object inheritance in DB. One overall
"base" model is real
On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
> This is my preferred choice, as well, but I'm not well-versed enough
> in the internals of Django to know if allowing empty models can
> create other problems outside of the admin interface. If anyone could
> point me to the relevant areas of cod
On Jun 21, 2006, at 4:49 PM, Malcolm Tredinnick wrote:
> What are the use cases for this sort of construction?
> [...]
I've always thought that any decent computer tool should either a) do
what you tell it to, or b) tell you why it can't/won't do what you
want it to (warnings, exceptions, et
On Wed, 2006-06-21 at 13:35 -0700, Tyson Tate wrote:
> I posted a ticket (#1972) a while ago and there's been a few other
> tickets reporting the same issue, so it sound like an issue that
> should be addressed.
>
> Basically: A model with no explicit fields doesn't get created by
> syncdb,
I posted a ticket (#1972) a while ago and there's been a few other
tickets reporting the same issue, so it sound like an issue that
should be addressed.
Basically: A model with no explicit fields doesn't get created by
syncdb, but syncdb doesn't throw any warnings or errors. Consider the
