Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Perth Hackfest October 2012/Custom fields and Metadata

From MoodleDocs
  • Current implementation is outdated
    • performance problem with user profile fields since it is not normalized
  • People want more fields for u
    • maybe use context, itemid, component identifier like files area comment etc
    • Remote Learner just uses contextid, contextlevel but this may not be enough for generalised solution
  • Use cases
    • Users
      • Alternative names (phonetic first and last name, multi-language names)
    • Courses
      • Alternative name for foreign language courses
      • licence could be migrated
      • Format refactoring for 2.4 will include new table to store options for format
    • Groups/Cohorts
  • Remote Learner
    • custom fields have type, ui (menu, text input, date selector, etc), uniqueness, access control to editing
    • custom fields used in search/reporting/automation/integration with external systems
    • multiple database tables to store different data types
    • need hooks in core forms for ‘are there custom fields on this thing? so put them here’

Spec contributors

  • Shane Elliott
  • Adrian Greeve
  • Justin
  • Jenny
  • Michael d

Needed very soon to allow engagement for some nations e.g. China, Japan


Spec

  • New database table that can be joined to existing tables, but quickly
  • Solution 1: Generic metadata data
    • Multiple tables for different types of data
    • Need an identifier like standard tuple: (contextid, component, area, itemid) for example
      • course, 321, 123, ‘bogans’
    • You would then need other tables to describe each custom field with custom type ID, type and name, eg
      • 321, string, ‘Alternate group name’

Advantages: Works across the whole range of metadata cases and custom fields


  • Solution 2: Extendable tables idea:
      • Allow new fields to be added to any table in Moodle (virtually)
      • Every Moodle table (eg user) can have one new table (extend_user)
      • Allow $DB functions to retrieve extended fields (via a parameter $includeextendedfields, default off) via simple join
      • Backup/restore easily supported
      • Advantages: very fast, clean, hackable
      • Disadvantages: not everyone keen on dynamic tables, and this only solves custom tables, is not useful for metadata across different objects in the site (such as authors, licenses, outcomes etc ...). These other cases need to implemented independently.
  • Add extra customdata field to all tables
      • one field containing serialised data - but this can’t easily be queried/searched
      • up to 4 fields - but these would have to be text so queries slower when matching integers, plus what if 5, 6, 7..
      • probably not a good idea
  • A view for user meta data

Use cases for metadata across the whole site:

Author

License

Outcomes

Custom fields for users, courses, groups, cohorts


Used in reports, marking tables