Topic on Talk:Files and licenses concept

Before we forget the plans from the Hackathon. From what I remember there were a paths we considered an option but we hadn't decided yet:

Scheme ideas

There were two main conceps:

1) mw_revision to mw_file_props

• Link between revisions and file properties:

  mw_revision get's a rev_fileprops_id which connects to mw_file_props.fp_id (just like revision.rev_text connects to mw_text.old_id)

• Identification of sets in mw_file_props:

  mw_file_props has an fp_id column which is "primary" but not unique or auto incrementing integer – since properties are in sets but also revisionised. fp_id is a counter for every 'set' and version of each 'set' (like revision but spanning multiple rows).

• Filepage (view or oldid) view

  MediaWiki looks up the correct entry in revision as usual with page.page_latest or oldid from URL. In there it finds rev_text and rev_file_props and it grabs from both tables the row with that specified id.

• Search in "current" fileprops / eg. List of works by X

  SELECT * FROM ?? WHERE ????? AND fp_key='author' AND fp_value_text='John Doe'FIX: @FIXME:

• Good:

  Most like the other tables in core. Search is probably good too.

• Bad:

  So far we haven't come up with a decent way to get this count for fp_id which is actually the only problem and if it weren't for that, this was the preferred scheme

  Not sure if the search query is good or not.

2) mw_file_props to mw_revision

• Link between revisions and file properties:

  mw_file_props has an fp_rev_id that is identical to the rev_id in mw_revision

• Identification of sets in mw_file_props:

  mw_file_props has an fp_rev_id column. (see previous point)

• Filepage (view or oldid) view

  MediaWiki looks up the correct entry in revision as usual with page.page_latest or oldif from URL. In there it finds rev_text but not an id in file_props, that one is reversed. It looks up in file_props where fp_rev_id is rev_id.

• Search in "current" fileprops / eg. List of works by X

  SELECT * FROM ?? WHERE ????? AND fp_key='author' AND fp_value_text='John Doe'FIX: @FIXME:

• Good:

  No schema change of mw_revision required

  Sets are identified with the rev_id when they were created. This allows an easy "File_props last edited by X on Y" seperate from the last modification of text.old_id by checking the rev_user of the rev_id in fp_rev_id.

• Bad:

  If a revision changes the wikitext but not the file properties, we have to, in order to keep the link between 'revision' and file_props' live, either:

  • A) Update current set of rows in file_props to the new fp_rev_id.

    Means that fp_rev_id will no longer indicate when the set was last changed. Not a big deal.

    Means that the set rows are touched eventhough nothing is being changed (bot edits will cause changes in file properties when only wikitext is changed)

  • B) Duplicate the row in file_props

    Dupes are never good.

    Means that fp_rev_id will no longer indicate when the set was last changed. Not a big deal.

• Krinkle 01:12, 16 January 2011 (UTC)