El , blye <blyen...@gmail.com> escribió:
Thank you for this very interesting projectIn my thoughts on web2py for
ed.
I have a problem of atomicity.(sic)
By this I mean :
Take a Multiple choice set of 10 questions. All models I have seen (so
far) essentially store one question per database table row. OK for very
small project.
But for large project Very large and unwieldy table.
I am thinking of holding let us say the ten multiple choice questions (
their details etc ) in One field in a row.( Maybe a Blob or a ref to a
pickle).
So a Set of questions ( One Exercise of many is One row of table)
My design challenge. Allow Input into forms as normal. On submit, store
input data temporarily without using table.
after Input loop ( eg 10 questions) , collate all Input data into Blob or
Pickle.
Store this as entry ( or reference ) into relevant field in row.
Then it needs an equivalent unpack so that the questions can be restored
and presented through the view. as if a normal table and rows.
This would make a Set the basic atom instead of the question.Much easier
down the line, student performance records etc. Scaleability.
I dont know if this is clear ;-)
It is above my web2py skills although I am experimenting.
Thank you for your work. I will add to project's issues list.
Thanks blye. I am not sure I will take this approach for storing exam data.
Here is why:
Suppose you want to search text trough it or build queries based in string
fields. Blobbing/pickling it in multiple record units would complicate the
simple database search feature provided by DAL with table inspection
algorithms (with the corresponding server performance issues). Another
concern of using it is that Pyodel questions are meant to be not just
simple statements, but markmin documents too, so there is also the
capability of carrying question related stuff like references, paragraphs,
media and other useful information for the exam.
However, we could think of adding simple one record question-answer sets
for small and quick tests and have one controller interface handle its data
in an exam type basis. Even we could use a quiz syntax for defining them in
one text field:
q-1: What happens when you activate the mechanism?
a-1: The cat in the box should be killed
a-2: The cat in the box should not be killed
a-3: Both
a-4: Nothing
c: a-4
q-2
...
Currently, I'm porting the app to a plugin structure, so it can be appended
to any web2py application.
