"Sean Jamieson" <[EMAIL PROTECTED]> writes:
> I've come across (or rather created:-/) a similar, but more interesting
> situation as Robin.
> Before I upgraded to 0.9a, I wrote a User class in 0.89, which had many
> similar fields as TG_User. In theory it makes sense to just factor
> those fields into a class that extends TG_User; which I did, altho this
> ended up creating a mostly empty User table, as most my added fields
> are MultipleJoins that create no field in the User table.
> One field was a ForeignKey to my Email table (this system stores
> multiple emails per user), this would conflict with/obsolete the
> emailAddress field in TG_User, making it redundant and useless to me.
>
> Also (yes there is more) I have another table for a different kind of
> user, which has another set of information ontop of User. It would make
> sense for this class to inherit User, thereby creating yet another
> table, that represents a grandchild of TG_User.
> My question: is this overkill? should I forget the inheritence and just
> do a one-to-one relation instead? it would seem to make much less of a
> mess out of my tables.
My opinion is that you *must* separate the two things: your model and your
program. Data representantion inside an RDBMS is very different from the OOP
paradigm. Each problem deserves one specific project.
I decided on letting my Auth part to identity's default tables and then making
a 1:1 mapping with another table that I use and is more complete to my needs.
Why? To avoid having to create my onw model, to be able to use different
providers (i.e. if I have a client with an LDAP base I won't force him to
insert all users again on the database, having two distinct bases for the same
thing...), and so on.
If you don't want to have this flexibility or if you need to tighten up your
system -- e.g. to make it usable and generic for everyone --, then creating a
custom set of tables might be a better choice. Then you'd ignore identity's
model and create your own and make identity use your model instead.
There are URLs on the archives and it looks not so hard to change that -- in
fact, at config.py there are options to use another class.
So... It all depends on what you want to do. There is flexibility enough to
adopt several solutions:
- 1:1 mapping
- developing your own model
- extending identity with inheritance
- creating a different provider
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
