On Thu, May 10, 2012 at 8:49 AM, Mitch S <mitchellsu...@gmail.com> wrote:
> Yes, you should be able to add database layer triggers in both MySQL and
> PostgreSQL
> ( http://dev.mysql.com/doc/refman/5.5/en/triggers.html and
> http://www.postgresql.org/docs/9.1/interactive/triggers.html )
> So you can leave the ODK Aggregate code entirely untouched.

> You'll want to pay attention to the IS_COMPLETE column in the top level
> table for a submission.  Until that is set to true, the record is not
> complete and may be missing one or more audio, video or image attachments.

> Mitch

> On Wed, May 9, 2012 at 6:22 PM, Trevor Ellermann <tre...@ellermann.net>
> wrote:

>> Hey Mitch,

>> You and I think a lot alike. I've spent the rest of the afternoon
>> installing the aggregate server on my own machine so I could look
>> directly at the database tables and upload scripts. I've been trying
>> really hard to avoid mucking with the ODK code but it's looking like
>> adding a hook to forward my database any copy of submissions might be
>> the way to go.

>> Thanks for the thoughts,

>> --Trevor
>> ___________________________
>> Trevor R. Ellermann
>> @trevorellermann
>> K0DMA

>> On Wed, May 9, 2012 at 5:37 PM, Mitch S <mitchellsu...@gmail.com> wrote:
>> > Or, if you host Aggregate on your own Tomcat instance, you can set up a
>> > database trigger on the Aggregate database tables and push the data to
>> > your
>> > own schema.  This would require a public IP address so the phones can
>> > publish to the server, and you have the SSL certificate process to wade
>> > through if you need https connectivity.

>> > Setting up a trigger would be part of the "upload form".  You could
>> > script
>> > this (so you could upload the form, then delve into the Aggregate
>> > database
>> > structures and establish the trigger).

>> > The database trigger isolates your app from the table structures used by
>> > Aggregate. I recommend not using those tables directly, as that would
>> > make
>> > your app very difficult to migrate to newer versions.  Going forward,
>> > the
>> > MODEL_VERSION and UI_VERSION fields will be consolidated into a VERSION
>> > string, for example.

>> > Mitch

>> > On Wed, May 9, 2012 at 3:46 PM, Trevor Ellermann <tre...@ellermann.net>
>> > wrote:

>> >> Copy that Waylon. Thanks for all of this information. I've joined the
>> >> dev list and will bring any further discussion on the JSON topic over
>> >> there.

>> >> I really appreciate you taking the time to let me know what is going
>> >> on with JSON. Now I just need to spend some time to figure out what is
>> >> the shortest path to getting data pushed back to my database.

>> >> --Trevor

>> >> ___________________________
>> >> Trevor R. Ellermann
>> >> @trevorellermann
>> >> K0DMA

>> >> On Wed, May 9, 2012 at 3:34 PM, W. Brunette <wbrune...@gmail.com>
>> >> wrote:
>> >> > To clarify a bit more JSON was in the 0.9.x versions and when being
>> >> > brought over to 1.x version of Aggregate. Changes to the protocols
>> >> > were requested and in the end the people requesting it didn't finish
>> >> > up the protocol specs. If you want to complete the protocol
>> >> > specification and provide the translation work to your protocol then
>> >> > we will be happy to include it.

>> >> > Waylon

>> >> > On Wed, May 9, 2012 at 3:30 PM, W. Brunette <wbrune...@gmail.com>
>> >> > wrote:
>> >> >> (please respond with anymore indepth questions to the developers
>> >> >> email
>> >> >> list).

>> >> >> The publishing to JSON was put on hold while we worked on a new
>> >> >> server
>> >> >> to server communication specification in JSON.

>> >> >> Here is a link to the source files

>> >> >> http://code.google.com/p/opendatakit/source/browse?repo=aggregate#hg%...
>> >> >> Basically all the files in external service do the post to the other
>> >> >> service.

>> >> >> There are two files JsonServer.java and OhmageJsonServer.java
>> >> >> because
>> >> >> of people losing interest those never got finished. If you would
>> >> >> like
>> >> >> to finish them we accept patches :) Basically people who were
>> >> >> interested were discussing different API options.

>> >> >> Aggregate actually manages the sending, and resending of data. It
>> >> >> just
>> >> >> doesn't know how to post to your desired server so Aggregate needs a
>> >> >> class that implements the ExternalService interface that posts the
>> >> >> submissions to the remote server.

>> >> >> http://code.google.com/p/opendatakit/source/browse/src/main/java/org/...

>> >> >> Waylon

>> >> >> On Wed, May 9, 2012 at 3:00 PM, Trevor Ellermann
>> >> >> <tre...@ellermann.net>
>> >> >> wrote:
>> >> >>> That form Submission API looks like exactly what I need for
>> >> >>> uploading
>> >> >>> forms. Thanks.

>> >> >>> As to changing the Collect code, It's actually part of the
>> >> >>> requirements that we don't do that. If I can just get publishing to
>> >> >>> JSON to work then I think I have all the pieces I need to get this
>> >> >>> working.

>> >> >>> Thanks again,

>> >> >>> --Trevor

>> >> >>> ___________________________
>> >> >>> Trevor R. Ellermann
>> >> >>> @trevorellermann
>> >> >>> K0DMA

>> >> >>> On Wed, May 9, 2012 at 2:49 PM, Yaw Anokwa <yano...@gmail.com>
>> >> >>> wrote:
>> >> >>>> Another option is to go at it from the phone side of things.

>> >> >>>> The form submission stuff is pretty straightforward -- it's
>> >> >>>> basically
>> >> >>>> an HTTP post.
>> >> >>>> https://bitbucket.org/javarosa/javarosa/wiki/FormSubmissionAPI

>> >> >>>> The code that does the post lives at

>> >> >>>> http://code.google.com/p/opendatakit/source/browse/src/org/odk/collec...

>> >> >>>> Using Aggregate -> Fusion Tables -> your app is potentially more
>> >> >>>> fragile because there are more pieces that could go wrong.
>> >> >>>> Changing
>> >> >>>> Collect has less pieces, but then you have your own version of
>> >> >>>> Collect
>> >> >>>> to maintain.

>> >> >>>> As far as automating transmission, that's pretty straightforward
>> >> >>>> if
>> >> >>>> you are familiar with Android. You need a background service that
>> >> >>>> watches for a network connection and calls the
>> >> >>>> InstanceUploaderTask.
>> >> >>>> Said service could also send on form save.

>> >> >>>> On Wed, May 9, 2012 at 2:36 PM, James Dailey
>> >> >>>> <jamespdai...@gmail.com>
>> >> >>>> wrote:
>> >> >>>>> You might consider publishing from Aggregate to google fusion
>> >> >>>>> tables
>> >> >>>>> then
>> >> >>>>> using available api to pull into your database.   PHP examples
>> >> >>>>> are
>> >> >>>>> given on
>> >> >>>>> Google site and rails gem is also available.

>> >> >>>>> On May 9, 2012 2:30 PM, "Trevor Ellermann" <tre...@ellermann.net>
>> >> >>>>> wrote:

>> >> >>>>>> Hello ODK Community,

>> >> >>>>>> I'm a developer and I have just been tasked with implementing
>> >> >>>>>> the
>> >> >>>>>> ability
>> >> >>>>>> to upload forms and get data back in to our own database in an
>> >> >>>>>> automated
>> >> >>>>>> fashion. Basically they just want to be able to click a button,
>> >> >>>>>> have it
>> >> >>>>>> upload the form and have submission data flow back into our
>> >> >>>>>> database with no
>> >> >>>>>> additional human input aside from people using the collector. Of
>> >> >>>>>> course they
>> >> >>>>>> want this done yesterday as well.

>> >> >>>>>> I see that ODK supports the OpenROSA API but I've never used
>> >> >>>>>> that
>> >> >>>>>> before.
>> >> >>>>>> I'm sure i can figure it out but in the interest of time I was
>> >> >>>>>> hoping there
>> >> >>>>>> was a primer on how to upload forms and get submissions back.
>> >> >>>>>> I'm
>> >> >>>>>> sure I'm
>> >> >>>>>> not the first person to do this but Google has not really
>> >> >>>>>> been yielding much
>> >> >>>>>> in the way of results. Does such a thing exist? Does anyone have
>> >> >>>>>> any advice
>> >> >>>>>> for me?

>> >> >>>>>> Any thoughts at all would be appreciated as I'm suddenly finding
>> >> >>>>>> myself
>> >> >>>>>> under and epic time crunch.

>> >> >>>>>> Thanks in advance,

>> >> >>>>>> --Trevor

>> >> >>>>>> --
>> >> >>>>>> Post: opendatakit@googlegroups.com
>> >> >>>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> >>>>>> Options: http://groups.google.com/group/opendatakit?hl=en

>> >> >>>>> --
>> >> >>>>> Post: opendatakit@googlegroups.com
>> >> >>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> >>>>> Options: http://groups.google.com/group/opendatakit?hl=en

>> >> >>>> --
>> >> >>>> Post: opendatakit@googlegroups.com
>> >> >>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> >>>> Options: http://groups.google.com/group/opendatakit?hl=en

>> >> >>> --
>> >> >>> Post: opendatakit@googlegroups.com
>> >> >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> >>> Options: http://groups.google.com/group/opendatakit?hl=en

>> >> > --
>> >> > Post: opendatakit@googlegroups.com
>> >> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> > Options: http://groups.google.com/group/opendatakit?hl=en

>> >> --
>> >> Post: opendatakit@googlegroups.com
>> >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> >> Options: http://groups.google.com/group/opendatakit?hl=en

>> > --
>> > Mitch Sundt
>> > Software Engineer
>> > University of Washington
>> > mitchellsu...@gmail.com

>> > --
>> > Post: opendatakit@googlegroups.com
>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> > Options: http://groups.google.com/group/opendatakit?hl=en

>> --
>> Post: opendatakit@googlegroups.com
>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
>> Options: http://groups.google.com/group/opendatakit?hl=en

> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitchellsu...@gmail.com

> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en