On Mon, Feb 04, 2008 at 08:32:17AM -0500, George Vilches wrote:
>Since we've been using a metaclass for doing a similar task, seems
>appropriate to paste it now:
>
>class ModelMixinBase(ModelBase):
>def __new__(cls, name, bases, attrs):
>new_attrs = attrs.copy()
>
On Feb 4, 2008, at 7:50 AM, Brian Harring wrote:
>
> This is a dirty hack mind you, but a rather effective one- I
> personally use it for when I need to create common structures w/in
> tables and need to able to change the structure definitions in a
> single spot. If you did the following-
>
>
On Sat, Jan 12, 2008 at 02:15:32PM -0500, Wanrong Lin wrote:
> I have a data model case that I think probably is quite common to other
> people too, and I did not find a way to do it with current Django, so I
> wonder whether the developers can take a look of it.
>
> My situation is:
>
> I
Thanks for your notices Wahrong.
1. by "syncdb.py" you do mean "manage.py syncdb", don't you? Thanks
for spotting, the table was not created anyway in fact (only the
confusing message was generated), but I corrected django/core/
management/commands/syncdb.py and will upload the latest patch
I searched the list and it seems the topic has been debated in summer
2006 but don't see any progress was made (at least from what I can see
in the mailing list). To me, model inheritance seems to be a very
important feature. I was hoping that the patch recently submitted by
Alex would solve
Hi, Alex,
Thanks for the update. I just tried the patch (on svn 7020), and found
two problems:
1. Even though the models with "create_db_schema=False" actually will no
longer have tables created in the database, when "syncdb.py" runs the
message still says those tables are created.
2. (More
Wanrong,
Just updated the ticket with the latest patch, which includes thorough
tests of the feature. Hope it now should be enough to commit, if the
gurus consider the code sufficient.
On 14 янв, 21:07, Wanrong Lin <[EMAIL PROTECTED]> wrote:
> Alex,
>
> Thanks a lot for this. Look forward to
Alex,
Thanks a lot for this. Look forward to the new version.
Wanrong
Alex Myodov wrote:
> Wanrong and Marc,
>
> I (the author of current #3163 patch) was just in the middle of the
> large email here explaining what I tried to do to create the tests,
> and what I could not, and where I need
Wanrong and Marc,
I (the author of current #3163 patch) was just in the middle of the
large email here explaining what I tried to do to create the tests,
and what I could not, and where I need help,... but was suddenly
stricken with the idea how I can write those tests. And the quick
experiments
Hi Wanrong,
It's hard to give predictions on open source projects, the last comment
on #3163 is advising that he/she cannot write the tests for some reason.
And without tests the ticket won't be checked-in.
You can always try to give a hand writting suchs tests. Once the ticket
has everything it
Hi, Marc,
This is great news. I am glad I have not re-written all my models with
all those duplicated stuff (I am sure that wouldn't make me feel I am
following the "DRY" principle).
Is it possible to give any prediction when this great stuff will be
checked in? Thanks a lot.
Wanrong
Marc
Hi Wanrong,
Maybe you could live with something like:
class common(models.Model):
...
Meta:
create_db_schema = False
class Model_B(models.Model):
...
Meta:
On 1/12/08, Wanrong Lin <[EMAIL PROTECTED]> wrote:
> I have a data model case that I think probably is quite common to other
> people too, and I did not find a way to do it with current Django, so I
> wonder whether the developers can take a look of it.
A search of the archive of this list will
This seems like somehting that would be implemented after model
subclassing is implemented.
On Jan 12, 1:15 pm, Wanrong Lin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have just started playing with Django and found it a pleasure to set
> up web site (even just a toy system so far) using the frame
14 matches
Mail list logo
