On Tue, Nov 17, 2015 at 2:56 PM Xavier Lamien <[email protected]> wrote:
> On Tue, Nov 17, 2015 at 11:05 AM Pierre-Yves Chibon <[email protected]> > 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? > -- Xavier
_______________________________________________ infrastructure mailing list [email protected] http://lists.fedoraproject.org/admin/lists/[email protected]
