Re: FAS2 to FAS3 DB migration - state and questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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 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
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux