(1) If your table has a fixed, known, unchanging, set of columns I
recommend implementing a storage class that derives directly from
CommonFieldsBase provides the primary key (_URI) and audit columns (
created-by, creation-date, last-updated-by, last-update-date). You can
search for uses of the above class to understand how to issue queries,
persist data, etc. against the table.
The FusionTable2ParameterTable class is entirely boilerplate, with the
definition of the 3 columns in the database table, accessors for those, and
the necessary code everywhere else to make everything work. Instances of it
hold a single row from the table. The interface to the datastore is via
(2) Alternatively, if you want to construct your tables on the fly (e.g.,
because you won't know how many columns they contain at compile time), or
if you want a more object-oriented interaction with the database layer, you
(2a) derive from org.opendatakit.common.ermodel.AbstractRelation -- an
example is in the integration/unit tests -- see RelationTest.
(2b) derive from org.opendatakit.common.ermodel.simple.Relation -- this is
used in the odktables code.
The first has somewhat better runtime performance. The second may be easier
to understand (or maybe not).
Long term, we expect to merge or eliminate one or the other of 2a or 2b.
On Wed, Aug 21, 2013 at 2:39 PM, wrote:
I would appreciate any help on this topic as I am a bit stuck. For my
application I need ODKAggregate to host a servlet that is connected to
PostgreSQL and can regularly send a list of rows from a table in PostgreSQL
when requested by ODK Collect. I have set up a servlet on Aggregate and an
activity on ODK that can interface with the servlet and receive XML
documents from the servlet. However, I can't figure out how to read from
the PostgreSQL database - there seem to be several layers of database
connectivity (DataManager, Relations, Entities, CommonFieldBases, etc.) and
I don't know which one is the best one to use? If all else fails I can set
up a JDBC connection from scratch, but I'd rather not do that if the
machinery is already there.
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to email@example.com.
For more options, visit https://groups.google.com/groups/opt_out.
University of Washington