mahara-contributors team mailing list archive

[Aaron Wells <1522309@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Mahara has a few prominent awkward database structures, that can be
considered examples of polymorphism and/or inheritance, in the data
structures we store in the database.

Some of the awkward tables:

1. The parallel tables for each plugintype: artefact_installed,
blocktype_installed, etc; artefact_cron, blocktype_cron, etc...

2. The multiple "owner" columns in the "view" table, which represent the
different types of entities that can own a view (or collection, or
artefact): view.owner, view.group, view.institution. This one has
actually caused bugs so far, due to the need to make these columns
nullable foreign keys, making it difficult to enforce the correct
uniqueness constraint on some of the other columns.

3. If we ever get around to implementing artefact permissions, and/or
multiple collections per page, we'll have a similar situation with the
"view_access" table.

So far we've either copied Moodle or taken an ad-hoc "reinvent the
wheel" approach to this issue. But there are actually a few known
strategies for dealing with these situations, each of which has its own
advantages and disadvantages. I think it would be good to summarize
those into a table in the developer section of the wiki, so that we can
make a more informed decision when implementing such tables in the
future, or considering to refactor the existing tables.

** Affects: mahara
     Importance: Wishlist
         Status: Confirmed


** Tags: database documentation standards

** Description changed:

  Mahara has a few prominent awkward database structures, that can be
  considered examples of polymorphism and/or inheritance, in the data
  structures we store in the database.
  
  Some of the awkward tables:
  
  1. The parallel tables for each plugintype: artefact_installed,
  blocktype_installed, etc; artefact_cron, blocktype_cron, etc...
  
- 2. The multiple "owner" tables in the "view" table: view.owner,
- view.group, view.institution. This one has actually caused bugs so far,
- due to the need to make these columns nullable foreign keys, making it
- difficult to enforce the correct uniqueness constraint on some of the
- other columns.
+ 2. The multiple "owner" columns in the "view" table, which represent the
+ different types of entities that can own a view (or collection, or
+ artefact): view.owner, view.group, view.institution. This one has
+ actually caused bugs so far, due to the need to make these columns
+ nullable foreign keys, making it difficult to enforce the correct
+ uniqueness constraint on some of the other columns.
  
  3. If we ever get around to implementing artefact permissions, and/or
  multiple collections per page, we'll have a similar situation with the
  "view_access" table.
  
  So far we've either copied Moodle or taken an ad-hoc "reinvent the
  wheel" approach to this issue. But there are actually a few known
  strategies for dealing with these situations, each of which has its own
  advantages and disadvantages. I think it would be good to summarize
  those into a table in the developer section of the wiki, so that we can
  make a more informed decision when implementing such tables in the
  future, or considering to refactor the existing tables.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1522309

Title:
  Specify a strategy for representing inheritance/polymorphism in the
  database

Status in Mahara:
  Confirmed

Bug description:
  Mahara has a few prominent awkward database structures, that can be
  considered examples of polymorphism and/or inheritance, in the data
  structures we store in the database.

  Some of the awkward tables:

  1. The parallel tables for each plugintype: artefact_installed,
  blocktype_installed, etc; artefact_cron, blocktype_cron, etc...

  2. The multiple "owner" columns in the "view" table, which represent
  the different types of entities that can own a view (or collection, or
  artefact): view.owner, view.group, view.institution. This one has
  actually caused bugs so far, due to the need to make these columns
  nullable foreign keys, making it difficult to enforce the correct
  uniqueness constraint on some of the other columns.

  3. If we ever get around to implementing artefact permissions, and/or
  multiple collections per page, we'll have a similar situation with the
  "view_access" table.

  So far we've either copied Moodle or taken an ad-hoc "reinvent the
  wheel" approach to this issue. But there are actually a few known
  strategies for dealing with these situations, each of which has its
  own advantages and disadvantages. I think it would be good to
  summarize those into a table in the developer section of the wiki, so
  that we can make a more informed decision when implementing such
  tables in the future, or considering to refactor the existing tables.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1522309/+subscriptions