Changes between Version 23 and Version 24 of ContribAuthImprovements


Ignore:
Timestamp:
Apr 16, 2012, 6:51:39 PM (13 years ago)
Author:
Jeremy Blanchard
Comment:

minor: typo

Legend:

Unmodified
Added
Removed
Modified
  • ContribAuthImprovements

    v23 v24  
    360360 * There is a *huge* migration task, since all existing User tables need to be migrated to the new profile-based format. However, we would be moving from one known format (old auth.User) to another well known format (new auth.User plus admin.!UserProfile), so the migration script will be reasonably predictable. When combined with delegated attributes, it should be possible to have a migration path that has all the usual warnings etc.
    361361
    362  * It requires joins to get to anything other than the core User data. There is some argument as to whether this is primarily a technical limitation or a social one. Mailing list discussions have indicated a preference by some people for a monolithic User object, avoiding the need for joins when retrieving user data. Although technical reasons are usually given for this preference (usually, "joins are evil"), it isn't clear that this is a a problem in practice -- at least to the extent that we should be basing the entire design around accommodating sites that area actually experiencing those problems.
     362 * It requires joins to get to anything other than the core User data. There is some argument as to whether this is primarily a technical limitation or a social one. Mailing list discussions have indicated a preference by some people for a monolithic User object, avoiding the need for joins when retrieving user data. Although technical reasons are usually given for this preference (usually, "joins are evil"), it isn't clear that this is a a problem in practice -- at least to the extent that we should be basing the entire design around accommodating sites that are actually experiencing those problems.
    363363
    364364 * If a new profile model is added to an existing project, new profile objects need to be instantiated for any existing User object. This is the analog of the problem in the "swappable-user" case; if the User model is modified, there is a migration task to make sure that the database User matches the code definition.
Back to Top