> On Tue, Aug 11, 2009 at 12:57:28PM -0300, Guilherme Salgado wrote: >> Another (simpler) option is to abuse the fact that the Person and >> Account tables are not linked by foreign keys and create the Person >> entry when needed but not link it to the existing Account. That way, >> everything would just magically work as the Person would seem to have no >> account. The only thing we'd have to do is change the registration/login >> (maybe reset password too) process to link the Person to the Account >> when they are not linked. Of course, by doing that we would also be >> hiding any bugs that might cause associated Person/Account entries to >> not be linked when they should.
Please don't abuse the data model :-P If you do that, the alerts that have been setup to detect this data corruption will go off. There should be foreign key constraints to ensure that all these links remain sane, and it is unfortunate that we cannot use them due to our replication requirements. The way we designed this situation to be handled is you create the person record and link it to the existing emailaddress and account if they exist. If we need to differentiate Person records created through these automatic approaches (imports from external bug trackers, pofile imports, branch imports, mailing list imports) from Person records being actively used, we should add flags. We should not extend the meaning of creation_rationale - new flags and fields is better. I certainly don't want to turn it into a bitmap field that makes it impossible to query sanely. I guess the main reason we want to differentiate users who have actively created a Launchpad Person from the import created Person is so we don't spam people who haven't signed up themselves (which would happen if someone subscribed them to a bug. I think an 'acivated' or 'deactivated' boolean would handle this - do we need something more complex than this? We should certainly create the Person records with a specific creation_rationale. We should certainly set the hide-emailaddress flag. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
