Re: Cross Importing Model Problem

2007-07-05 Thread Bryan Veloso

Oh also, I thought OneToOneFields were discouraged in favor of
ForeignKeys with unique=True as per
http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Cross Importing Model Problem

2007-07-05 Thread Bryan Veloso

Thanks for the help guys. Splitting the models up was mostly a
cosmetic thing for the admin, but these problems quickly kicked me out
of that state. Anyway, yes, the database design is really bad, mostly
because that's not what the game developers are experts at
unfortunately.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Cross Importing Model Problem

2007-07-05 Thread Nis Jørgensen

Bryan Veloso skrev:

(I am only commenting on the model (database and Django) in this post -
I don't really know enough about imports to help you with that bit)

> I have 2 models for an MMORPG control panel I'm building. Each set of
> data is within it's own app with related models, etc. So here's my
> example. It's run off an existing database so I really can't change
> any of the database fields.
>   
It seems some of the tables are not normalized (see below). Are they set
in stone?

> I have a Character model that imports the Guild model.
>
> class Character(models.Model):
> char_id = models.IntegerField('Character ID',
> primary_key=True)
> account = models.ForeignKey(Account, unique=True,
> db_column='account_id')
> char_num= models.IntegerField('Character Slot')
> name= models.CharField('Name', maxlength=90)
> guild   = models.ForeignKey('Guild',
> db_column='guild_id') 


As far as I can see, this

account = models.ForeignKey(Account, unique=True,
db_column='account_id')

is equivalent to
account = models.OneToOneField(Account, db_column='account_id' )

but with a simpler interface ("account.character" rather than
"account.character_set.all()[0]".

You might want to consider this change - although it might be a bad idea
if you envision multiple characters per account int he future.
> But the app that contains Guild has another model that is linked to
> the Character model.
>
> class GuildMember(models.Model):
> guild   = models.ForeignKey(Guild,
> db_column='guild_id', unique=True, primary_key=True)
> account = models.ForeignKey(Account,
> db_column='account_id', unique=True)
> character   = models.ForeignKey(Character,
> db_column='char_id', unique=True) 
>   
The use of "unique=True" here looks wrong. As written, a Guild has at
most one Character, and a Character has at most one Guild. Is this
really what you want? If so you might again consider using two
OneToOneFields. But I suspect you really mean 'unique_together
(('guild'),('character')).

Anyway, the database design looks quite bad ... the "account" field in
GuildMember seems redundant (assuming it points to the account of the
character). It is not clear whether Character.guild corresponds to
Character.guildmember_set()[0].guild - if they are always the same, the
table structure is not normalized.

I guess the root cause of your problems is that you cannot easily model
a ManyToMany relationship between models in different apps. As Malcolm
suggests, the solution is probably to not have two apps.

Nis



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Cross Importing Model Problem

2007-07-04 Thread Malcolm Tredinnick

On Wed, 2007-07-04 at 23:06 +, Bryan Veloso wrote:
> I don't know if this is even possible, since I've had so many errors
> thrown at me, but I wanted to ask here so I can get a clear picture.
> 
> I have 2 models for an MMORPG control panel I'm building. Each set of
> data is within it's own app with related models, etc. So here's my
> example. It's run off an existing database so I really can't change
> any of the database fields.
> 
> I have a Character model that imports the Guild model.
> 
> class Character(models.Model):
> char_id = models.IntegerField('Character ID',
> primary_key=True)
> account = models.ForeignKey(Account, unique=True,
> db_column='account_id')
> char_num= models.IntegerField('Character Slot')
> name= models.CharField('Name', maxlength=90)
> guild   = models.ForeignKey('Guild',
> db_column='guild_id') 
> 
> But the app that contains Guild has another model that is linked to
> the Character model.
> 
> class GuildMember(models.Model):
> guild   = models.ForeignKey(Guild,
> db_column='guild_id', unique=True, primary_key=True)
> account = models.ForeignKey(Account,
> db_column='account_id', unique=True)
> character   = models.ForeignKey(Character,
> db_column='char_id', unique=True) 
> 
> So when I run it, it says it can't import Character & Guild. Which
> makes sense because I'd be importing a model onto itself. Is there any
> way to get around this? I thought if you called a model that it would
> only import the dependencies related to the model being imported,
> rather than all the dependencies in models.py.

Importing a file processes the whole file. That's the way Python works.
This includes parsing all code at the top level, including class
descriptions like you've got here.

One solution which is recommended to get around circular import problems
is not to import the remote name into the current namespace. Instead,
import the module containing the object you want to access. For example,
instead of

from my_app.models import Character

use

from my_app import models as my_app_models

(using an alias, since "models" might be used elsewhere).

However, having said that, I suspect you might still have some problems
as Django is going to need access to all the internal details as part of
the __new__ method, which might mess things up. We might make this
easier one day (it's been shot down in the past, but it might be worth
revisiting at some point; not soon, though, since we're busy on other
things).

It does force me to ask the question though: if GuildMember depends on
Character *and* Character depends on GuildMember, why are they in
separate applications? They are very tightly bound to each other, so you
can't exactly take one of the apps and use it without the other one.
This looks like false separation of responsibilities a bit.

If you really need them in separate apps and the above technique doesn't
resolve the problem, use a GenericRelation for one of the relations;
that should help.

Regards,
Malcolm

-- 
I intend to live forever - so far so good. 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---