View source for Database Storage Engine Project Meeting Log


__TOC__

On this page you can find the decisions made at the DBSE project meetings.

=2010-05-14=
*We will use a plug-in like structure for meta-data linked to questions. (as decided before, questions will also be implemented in a plug-in like structure in order to make adding new types of questions easy)
*A prototype of the system will be implemented before the GSOC midterm deadline.
*A basic version of the API will be posted on the forums in the following weeks to give the community plenty of time to give input on what interfaces should be provided. We will focus on building the basic API. It will be possible to add more advanced statistical procedures later on.

=2010-05-21=
*The basic API will be ready by Monday (05-24) and posted on the wiki page in order to discuss it at the developer meeting the day after. This way we can get developer input before releasing the API in order to get input from the community.
*The API will support operations for ALL database layouts. Because some features are possible in only some kinds of databases, there will be a "supports" function and flags for the supported features.
*We will not support looping in the flat database layout since this will lead to sub-structures in the database. This leads to inefficient retrieval of answers, which defeats the reason to use this database structure.
*Added a TODO to the list for the database designs: make sure we have solutions for all LS1 question types. (see [[Question types]])
*Classes QuestionType, Structure, Section, Survey will inherit from an Element class. This class will support conditions. This means it will be possible to place conditions on questions, structures, sections and surveys (for example only people with local ip addresses can answer the survey).
*More generally we decided LS2 should be able to support single question surveys (for example for websites wanting to use LS for a poll-system). To enable this, a secondary controller can be made which will support basic operations like answer() and getAnswers().

NOTE: we would like to point out the DBSE controllers will not be what CakePHP calls "controllers". The controllers will be actual controllers for internal coding use and will not be accessed directly through the website.

=2010-05-28=
*We will use exceptions instead of returning true/false to indicate errors when calling the API.
*Metadata keys will be unique. Metadata methods will be changed accordingly.
*We will use dot-notation for metadata subkeys (for example color.red indicates master key 'color' with subkey 'red').
*The name of a token will be changed to participantID to increase understandability.
*The participantID's will be provided by systems outside of the DBSE. This will enable the use of external user systems.
*We will add a "participated" method to see if a certain participant finished the survey.

=2010-06-13=
*The DBSE API has been posted on the forums, awaiting community input.
*Multiple-choice answers will be stored in an extra table and not in question metadata. Answers will also have metadata.
*QuestionTypes will use a plugin based system. The QuestionTypes will be placed in a folder which will contain one subfolder for each question type. In this folder there will be the class file and a template file. There will be conventions for the names of these files.
*Internationalization will be done by an extra system. The DBSE system will store information about one language: the base language. The external system will receive updates under the form of the Observer pattern.
*Question types are not to be deleted. When updating a question type, backwards compatibility is to be ensured by the developer.
*Primary keys will not change (meaning IDs and metadata-keys will not change).

=2010-06-20=
* We will not store metadata of responses except for start and end times of every survey/section/question.
* Times will be given to the answer() method in the API. The DBSE system will assume the given times are correct.
* Because there is no clean way to express the designs for the responses, we will add examples how the important question types of LS1 can be mapped to the database.

=2010-07-02=
* The database designs have been finished. [[Database Storage Engine Project M1 Database Design|Database Designs]]
* The DBSE API has been finished. [[Database Storage Engine Project M2 API|API]]
* We will put 'DBSE' in front of the DBSE classes since we cannot use namespaces. This will make the code easier to read and avoid possible naming conflicts.
* We changed the StringQuestionType to a longtext (used to be varchar(255)) to allow longer input.
* We will create different exception classes which inherit from a general DBSEException parent class.

=2010-07-10=
* The DBSE controllers will be renamed to components since they will be cake components.
* The AnswerAccess controller will be renamed to ResponseAccess.
* Cake supports 'text' as a database type yet it does not support longtext. This might be a problem. Jason will contact a cake developer about the problem.
* We will not add a controller to add question types. A controller can be added later. Currently installing a new type is done by placing the class and template file in the questiontypes folder.
* We will not add a controller to add database engines. They will be cake plugins. To install a new engine, you will need to change a config file in the DBSE plugin.
* We will not perform checks before updating fields. If there is an error because a database field is not unique, we throw an exception based on the sql error.
* Currently we are using dropbox to share prototype code. Once we have configured our svn clients, we shall commit the code.

=2010-07-25=
* We discussed the new [[Database Storage Engine Project|#Milestones|milestones]]. Maarten will take care of the testing and debugging of the application while Pieter-Jan will be implementing the rest of the project.
* We will use the survey end time as a check to see if the user has finished the survey. The end time has to be set by calling a finishSurvey(participant_id) method.
* The hasFinished() method will use the end time of the survey to check if the survey is finished by a participant. We will not check if all the given answers are valid since this is impossible (the conditions engine has a huge effect on this check).
* Survey and section begin and end times will be added to a response.
* Responses will continue to have participant id's yet when using getResponses() and getResponsesToQuestion() will get a setParticipants argument. When set to false (default) the participants will not be added to the responses and anonymous responses will be returned.
* We discussed the problem we have with the plugin bootstrap and configuration file. We will include this file in the application's bootstrap file.
* We decided we will update the tables for the responses when a survey is updated rather than dropping and creating them. This means the data in the tables will continue to be there. The data might become inconsistent due to bad updates (a question might become mandatory where it wasn't). We will not handle these inconsistencies.

=2010-08-01=
* We will add a template to question types for the question configuration.
* We will provide helpers for the settings and for the model answers. These can be used in the configuration template.
* We will add a method which will return a list of settings (which can be fed to the helper).
* We will add a parent template for all questions. This template will contain the question text, helptext and if the question is mandatory or not.
* We will base the new templates on the existing LS2 templates.
* We will implement a basic set of question types. These will be: StringQuestionType, TextFieldQuestionType, ChoiceQuestionType, CheckboxQuestionType, MatrixQuestionType and ChoiceMatrixQuestionType.

=2010-08-08=
* We discussed the progress of the last weeks: the question types and the tests are finished.
* During the next week, we will be updating the documentation on the wiki.
* Also next week we will clean up some of the latest code to make it more readable.