Randall wrote:
> As it is currently written, subclassing will create additional tables
> that contain the "extra" attributes, so each class (User, Group,
> Permission) requires two tables instead of one. It will work, but it
> is ugly. Also, in my experience, setting properties on the subclass
> (e.g. _set_password) does not work. My solution was to create User,
> Group and Permission classes that don't inherit from the soprovider
> classes. The downside to this is that I don't inherit anything and I
> would bet the jsonify stuff doesn't work because my classes don't
> inherit from TG_*.
>
+1, I also thing the two tables are ugly (very ugly IMO) and are a pain
to integrate with other ways to access the database (via psql, for
example, I mean, how could I explain my client how they should
hand-tweak the user tables using a plain ol' SQL UPDATE?? ).
> I propose that the TG_User, TG_Group and TG_Permission inherit from
> SQLObject. This way, only one table will be created for a subclass and
> setting properties should work. Also, everything else in the module
> (jsonify_group) should keep working.
I'm not very sure about this, If I remember correctly, when I was
playing for the first time with SQLObject that subclassing SQLObject
instances did not work as expected, I don't remeber exactly in what
ways, though...
RFC:
What I propose is a simplification of the tables, that is, the bare
minimum the identity framework needs to work so we can concentrate on
keeping that stable so it doesn't break on future releases.
That is:
class TG_User(InheritableSQLObject):
# Inheritable just in case someone still wants to use the current
inheritance mechanics
# userId is the pseudo "primary key" used by the rest of the
framework
userId= UnicodeCol( length=16, alternateID=True )
# password just needs to be there to properly validate
password= UnicodeCol( length=40 )
# we need relations :)
groups= RelatedJoin( "TG_Group", intermediateTable="tg_user_group",
joinColumn="user_id", otherColumn="group_id" )
class TG_Group(InheritableSQLObject):
# ditto
groupId= UnicodeCol( length=16, alternateID=True )
# ditto
users= RelatedJoin( "TG_User", intermediateTable="tg_user_group",
joinColumn="group_id", otherColumn="user_id" )
#ditto
permissions= RelatedJoin( "TG_Permission", joinColumn="group_id",
intermediateTable="tg_group_permission",
otherColumn="permission_id" )
class TG_Permission(inheritableSQLObject):
#ditto
permissionId= UnicodeCol( length=16, alternateID=True )
# ditto
groups= RelatedJoin( "TG_Group",
intermediateTable="tg_group_permission",
joinColumn="permission_id",
otherColumn="group_id" )
The rest of the current columns, IMO, are application specific... and
shouldn't be there. I personally don't care when a group was created
neither I use a displayName: I have a firstName and lastName and
__unicode__ for... displaying.
What i'm suggesting with this is, given that sqlobjects are a pain to
subclass, we should not even subclass them. Just create our app
specific models with the bare attributes the identity framework needs
and add our application specific stuff as we might need. We could even
make a quickstart template that generates a custom id_model at the
newly created project so users can easily customize further from there.
jsonify_* should work as expected (but a small tweak has to be done to
the generic dispatcher's conditions to use the custom classes defined
at config.py, probably this is the ONLY change needed, but haven't
tested to be sure).
I'm willing to volunteer to apply the needed changes if there is a
consensus.
Opinions?
Alberto
P.S. I know these are not identity framework's inherent limitations,
just the way InheritableSQLObject happens to work. And I really
appreciate the work Jeff has done on this, but that doesn't mean it
can't be improved.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
