Note:

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

DB layer 2.0: Difference between revisions

From MoodleDocs
Line 14: Line 14:
** Full abstraction: Hide underlying libraries (adodb, pdo...) and drivers to Moodle developers completely.
** Full abstraction: Hide underlying libraries (adodb, pdo...) and drivers to Moodle developers completely.
** Make it so that the database object can be subclassed - this means for unit tests that want to test database access, the test framework can override necessary methods
** Make it so that the database object can be subclassed - this means for unit tests that want to test database access, the test framework can override necessary methods
** support ? and :param and $1 parameter types
** support ? and :param parameter types (independently of the param types supported by each driver).
** global $DB
** global $DB
** profiling, logging and exceptions
** profiling, logging and exceptions

Revision as of 22:42, 22 May 2008

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


Objectives

  • Switch to prepared statements - using placeholders and preparing statements protects against sql injection
  • Remove the need for data to be add/strip slashed all over the place in the code.
  • Enable easier and productive unit tests.

Requirements

  • 100% cross-db
  • OOP implementation:
    • Full abstraction: Hide underlying libraries (adodb, pdo...) and drivers to Moodle developers completely.
    • Make it so that the database object can be subclassed - this means for unit tests that want to test database access, the test framework can override necessary methods
    • support ? and :param parameter types (independently of the param types supported by each driver).
    • global $DB
    • profiling, logging and exceptions
  • Easy to use (consistent and similar to current dmllib 1.0)
  • Easy to migrate (provide documentation and utilities to help on that)
  • Complete unit testing (self)
  • Easy unit testing (moodle - real and mockup)
  • Well documented (PHPDocs + use examples)
  • Tasks, bugs and progress tracked in MDL-14679
  • Due date: N/D

Meetings

Ideas