does OTrunk send back empty bundles (no SockEntries)? Is this what it looks like?
Stephen Bannasch
and doesn't change anything?
>> puts bc1.body
<sessionBundles xmlns:xmi="http://www.omg.org/XMI"
xmlns:sailuserdata="sailuserdata"
start="2009-08-07T03:40:56.987-0400"
stop="2009-08-07T03:41:09.550-0400"
curnitUUID="cccccccc-0009-0000-0000-000000000000"
sessionUUID="266bc667-c948-45d6-94a7-ed201ed94525"
timeDifference="1812" localIP="71.234.33.35">
<agents role="RUN_WORKGROUP"/>
<sdsReturnAddresses>http://rites-investigations.concord.org/dataservice/bundle_loggers/107/bundle_contents.bundle</sdsReturnAddresses>
<launchProperties key="previous.bundle.session.id"
value="2a78cc67-e46b-4085-92b8-4b619ea3600e"/>
<launchProperties key="maven.jnlp.version"
value="all-otrunk-snapshot-0.1.0-20090731.193831"/>
<launchProperties key="sds_time" value="1249630856987"/>
<launchProperties key="sailotrunk.otmlurl"
value="http://rites-investigations.concord.org/investigations/415.otml"/>
</sessionBundles>
23 out of 483 bundles on the RITES production server have no
<SockEntries /> element.
Stephen Bannasch
>Is this what OTrunk sends back when a learner complete's a session
>and doesn't change anything?
In some circumstance it appears the answer is yes.
I logged in to the rites dev server as the student: 'student' and ran
the Investigation 'States of Matter - MS' five times, four of the
times I saved a snapshot.
After the first session I started up a script console session on the
rites dev server.
The session was requesting config data for learner 105 so I started there:
>> l105 = Portal::Learner.find(105)
=> #<Portal::Learner id: 105, uuid:
"8fe1bdf2-8325-11de-9bea-001ec94098a1", student_id: 1, offering_id:
25, created_at: "2009-08-07 07:40:21", updated_at: "2009-08-07
07:40:21", bundle_logger_id: 107, console_logger_id: 107>
Anfter the first session there was one bundle_content object saved.
>> bl = l105.bundle_logger
=> #<Dataservice::BundleLogger id: 107, created_at: "2009-08-07
07:40:21", updated_at: "2009-08-07 07:40:21">
>> bl.reload; bl.bundle_contents.each_with_index { |bc, i| puts
>>"#{i}: #{bc.id}, #{bc.body.length}, empty: #{bc.empty}" } ; nil
0: 510, 48273, empty:
=> nil
After running the Investigation twice and saving another snapshot
each time there were now three bundle_content objects:
>> bl.reload; bl.bundle_contents.each_with_index { |bc, i| puts
>>"#{i}: #{bc.id}, #{bc.body.length}, empty: #{bc.empty}" } ; nil
0: 510, 48273, empty:
1: 511, 94192, empty:
2: 513, 140043, empty:
=> nil
I started the fourth session and immediately quit:
>> bl.reload; bl.bundle_contents.each_with_index { |bc, i| puts
>>"#{i}: #{bc.id}, #{bc.body.length}, empty: #{bc.empty}" } ; nil
0: 510, 48273, empty:
1: 511, 94192, empty:
2: 513, 140043, empty:
3: 514, 860, empty: true
=> nil
The empty flag indicates there there was no otml data at all in the
session bundle.
I added a new association which should get the right bundle -- and it
skips 514 and gets 513:
>> bl.last_non_empty_bundle_content.id
=> 513
After running one more session and saving another snapshot to go with
the first three here's what the five sessions look like:
>> bl.reload; bl.bundle_contents.each_with_index { |bc, i| puts
>>"#{i}: #{bc.id}, #{bc.body.length}, empty: #{bc.empty}" } ; nil
0: 510, 48273, empty:
1: 511, 94192, empty:
2: 513, 140043, empty:
3: 514, 860, empty: true
4: 515, 185919, empty:
=> nil
>> bl.last_non_empty_bundle_content.id
=> 515
Scott Cytacki
has no learner data.
So instead of sending all of the old data back it was sent empty.
And the sds would just skip these bundles.
You should be able to find that logic both in the java code and the sds
code.
Scott
Stephen Bannasch
>I do now remember we had some approach for dealing with a bundle that
>has no learner data.
>So instead of sending all of the old data back it was sent empty.
>And the sds would just skip these bundles.
>
>You should be able to find that logic both in the java code and the sds
>code.
I've already implemented what appears to be a robust logic for
dealing with these empty bundles as outlined in the previous message.
Save all bundles in a sequenced list by order of creation in the dataservice.
When a bundle_content model is saved:
extract the otml and set the boolean flags: valid_xml and empty.
When a bundle_logger is asked for a bundle_content object in the
learner controller:
return the most recent, valid and not empty bundle OR an empty bundle
Is there something missing from this logic that you noticed?
Scott Cytacki
Something that should also be there is a way to reorder the bundles.
Or perhaps simpler is to flag a particular bundle as the one that should
be sent down on the next request.
Scott
Stephen Bannasch
>That basic logic looks good.
>
>Something that should also be there is a way to reorder the bundles.
>Or perhaps simpler is to flag a particular bundle as the one that should
>be sent down on the next request.
The ordering is done with acts_as_list so re-ordering is easy.
Are there situations you can think of (other than an admin fixing
something) where bundle re-ordering might be useful?
Separately it should be easy using the current model implementation
to refer to any particular bundle and preview the learners work at
any selected point in session sequence.