On Tue, Nov 17, 2015 at 2:56 PM Xavier Lamien laxathom@fedoraproject.org wrote:
On Tue, Nov 17, 2015 at 11:05 AM Pierre-Yves Chibon pingou@pingoured.fr wrote:
Good morning everyone,
I started looking at what it will take to migrate data from FAS2 to FAS3.
Here are my findings.
First of all the DB schemas: FAS2: http://ambre.pingoured.fr/public/FAS2.png FAS3: http://ambre.pingoured.fr/public/FAS3.png
Tables to delete in FAS2:
- session
- migration_version
- visit
- vistit_identity
- configs
- requests
- samadhi_associations
- samadhi_nonces
- group_roles
Tables of FAS2 I do not know what to do with:
- Log We have some logs in the DB, we might be able to convert them but the
amount of information missing for the new log table (people_activity_log) might not make it worth
- bugzilla_queue There are a few entries in there, but I do not know what it is meant
for nor used by
- Tables to migrate
- person_roles -> group_membership in FAS3
- person_roles_fpca -> group_membership in FAS3 -> I guess created when we changed from CLA to FPCA so to be merged
in the same one as above
- groups -> group in FAS3
- people -> people in FAS3
- Fields that changed
people username : FAS2 = varchar(32) -> FAS3 = varchar(255) fullname : FAS2 = human_name -> FAS3 = fullname avatar : FAS2 = blog_avatar? -> FAS3 = avatar password : FAS2 = varchar(127) -> FAS3 = text gpg_id : FAS2 = gpg_id -> FAS3 = gpg_keyid emailtoken: FAS2 = emailtoken -> FAS3 = email_token passwordtoken: FAS2 = passwordtoken -> FAS3 = password_token status : FAS2 = text -> FAS3 = int alias_enabled: FAS2 = alias_enabled -> FAS3 = email_alias last_seen : FAS2 = last_seen -> FAS3 = last_logged
group name : FAS2 = varchar(32) -> FAS3 = varchar(40) url : FAS2 = url -> FAS3 = web_link groupe_type: FAS2 = varchar(16) -> FAS3 = int (Foreign Key) creation : FAS2 = creation -> FAS3 = created joinmsg : FAS2 = joinmsg -> FAS3 = join_msg user_can_remove: FAS2 = user_can_remove -> FAS3 = self_removal
For this table I have a problem with these fields in FAS3: ``need_approval`` and ``requires_sponsorship``? What is the difference? Which corresponds to ``needs_sponsor``?
There were no real difference in between those two in FAS2 both were doing the same thind. In FAS3, the need_approval boolean is used when the group doesn't provide "sponsor" role. in this context, groud's admin can approve users without having (or being) a sponsor's role (like in fas2) which actually doesn't mean anything for this group's purpose.
group_membership role_type: FAS2 = role_type (text) -> FAS3: role (int) role_status: FAS2 = role_status (text)-> FAS3: status (int) sponsor_id: FAS2 = sponsor_id -> FAS3: sponsor person_id: FAS2 = person_id -> FAS3: people_id creation: FAS2 = creation -> FAS3: creation_timestamp approval: FAS2 = approval -> FAS3: approval_timestamp
Xavier, could you confirm that this mapping is correct? Should we look into being a little closer to the FAS2 model? (For example in the group_membership table)
I don't think we should. This will make think more complicated by adapting fas3 code which come with a new architecture.
Also for change such as the length of the password field, since we hash the
password, does it make sense to use a text field there since they will all be of the same size?
If the the length from fas2 is the same as fas3, not really.
Then there is the question of the integer-based status (in the `people` table and in the `group_membership` table). Is the mapping documented somewhere? Does it fit with the old status model?
Another question will be regarding the certificates, Xavier, will we be able to migrate certificates information to the new tables?
We should be able to. what king of info is being missed in fas3?
infrastructure@lists.fedoraproject.org