On Tue, Nov 17, 2015 at 2:56 PM Xavier Lamien <laxathom(a)fedoraproject.org>
wrote:
On Tue, Nov 17, 2015 at 11:05 AM Pierre-Yves Chibon
<pingou(a)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?