Hi all,
As discussed previously on multiple occasions Chamilo 2 supports the
implementation of multiple storage engines. Up untill now the only
supported engine has always been MDB2 (love it, hate it, it's irrelevant
in this context). As part of their exploration of Chamilo 2, the people
from Claroline as well as Norman Scorm-expert ;-) have made several
suggestions for alternate storage engines. While they could be
implemented without much (any?) problems, it wasn't all too clear what
could be reused and what had to be reimplemented.
To facilitate this I set about splitting up the code a bit more, getting
rid of ambiguous names like "database", etc.
A short overview of the changes:
1. "Storage" related classes are now located in the
common\libraries\storage folder. The root contains all generic
classes (providing abstraction and/or interfaces), each specific
implementation has it's own subfolder.
2. Some classes have been deprecated, most notably ObjectResultSet
and RecordResultSet. We obviously still map results from the
storage engine to objects, but we now do so directly by invoking
an extension of the generic ResultSet. In the case of MDB2 this
would be Mdb2ResultSet. Functionality as such has not changed. If
you still need the actual record instead of an object you can
however pass "false" to your call to next_result(). It will
however allways convert to an object if not instructed otherwise.
We strongly advise to not use records.
3. DatabaseAliasGenerator was renamed to StorageAliasGenerator
4. Worth noting is that the ConditionTranslator also contained some
semi-specific code for DBMS'. While this code should work with
most DBMS implementations, it is virtually useless for e.g.
in-memory implementations, flat file storage and whatever else
anyone may want to implement somewhere down the road. To avoid
this being a bottleneck, the class itself was abstracted as well.
Apart from of course having to implement a ConditionTranslator for
you storage engine, please also keep in mind that this has some
consequences for the way we call the Translator. This used to be
something like new ConditionTranslator ($this, $storage_unit).
While this still works in the context of a specific
implementation, it is no longer valid for generic usage. The best
way to call the ConditionTranslator, from now on, is
ConditionTranslator :: factory($this, $storage_unit); Considering
that $this is our actual DataManager implementation, it can be
used to automatically determine the type of the implementation and
return an instance of the correct type of ConditionTranslator.
Apart from this, nothing has changed for conditions, they are
still generic.
5. The "old" DatabaseRepositoryDataManager classes and so on have
been renamed to Mdb2RepositoryDataManager. This should have been
fixed platformwide, but please do test your applications. Related
to this the filename of said classes was changed from
type_application_data_manager.class.php to type.class.php.
Considering that paths tend to become exceptionally long as it is
already, this seemed like a good way to save some space.
6. Some work remains to determine once and for all the completeness
and correctness of our DataManager interfaces, please feel free to
tune in if and when you find something which is missing from the
interfaces but IS being called directly from outside the context
of the DataManager implementations.
Best regards,
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
