view tests/0020/run-test.sh @ 133:a5d5a55a412d

Friendlier Actionscript/SOAP behaviour. As suggested in the gsoap documentation, we wrap the struct that we actually want to return inside a response structure. (It should be said that I didn't understand a _word_ of the gsoap documentation; I want in particular to highlight section 8.1.1 of the gsoap 2.7.6 user guide, which reads in its entirety "If the single output parameter of a remote method is a complex data type such as a struct or class it is necessary to specify the response element of the remote method as a struct or class at all times. Otherwise, the output parameter will be considered the response element (!), because of the response element specification convention used by gSOAP, as discussed in 8.1.7." and tells me absolutely nothing of use.) Nevertheless, cargo-cult from the documentation...
author mas01cr
date Tue, 23 Oct 2007 17:21:08 +0000
parents 9967d4dc6b1f
children fe4dc39b2dd7
line wrap: on
line source
#! /bin/sh

. ../test-utils.sh

if [ -f testdb ]; then rm -f testdb; fi

${AUDIODB} -d testdb -N

intstring 2 > testfeature01
floatstring 0 1 >> testfeature01
intstring 2 > testfeature10
floatstring 1 0 >> testfeature10

${AUDIODB} -d testdb -I -f testfeature01
${AUDIODB} -d testdb -I -f testfeature10

# sequence queries require L2NORM
${AUDIODB} -d testdb -L

start_server ${AUDIODB} 10020

echo "query point (0.0,0.5)"
intstring 2 > testquery
floatstring 0 0.5 >> testquery

${AUDIODB} -c localhost:10020 -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput
echo testfeature01 1 > test-expected-output
echo testfeature10 1 >> test-expected-output
cmp testoutput test-expected-output
${AUDIODB} -c localhost:10020 -d testdb -Q sequence -l 1 -f testquery -r 1 -R 5 > testoutput
echo testfeature01 1 > test-expected-output
cmp testoutput test-expected-output

check_server $!

echo "query point (0.5,0.0)"
intstring 2 > testquery
floatstring 0.5 0 >> testquery

# FIXME: because there's only one point in each track (and the query),
# the ordering is essentially database order.  We need these test
# cases anyway because we need to test non-segfaulting, non-empty
# results...

${AUDIODB} -c localhost:10020 -d testdb -Q sequence -l 1 -f testquery -R 5 > testoutput
echo testfeature01 1 > test-expected-output
echo testfeature10 1 >> test-expected-output
cmp testoutput test-expected-output
${AUDIODB} -c localhost:10020 -d testdb -Q sequence -l 1 -f testquery -r 1 -R 5 > testoutput
echo testfeature01 1 > test-expected-output
cmp testoutput test-expected-output

stop_server $!

exit 104