On Tue, Nov 17, 2015 at 2:56 PM Xavier Lamien <laxathom@xxxxxxxxxxxxxxxxx> wrote:
On Tue, Nov 17, 2015 at 11:05 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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 codewhich 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?
--
Xavier
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
