[Cronometer-development] Measure/Serving in the database

[Chris R. <of...@gm...>]

I'm thinking of moving Measure and Serving over to the same interface
format as Food -- this would force creation of Datasource-specific
models of each of them which may or may not be what we want.

A couple of reasons for this:

One, both of them are essentially first-class objects in the backing
datastore.  Measures and Servings have their own tables, and their own
unique IDs.  This suggests pretty strongly that they should be
represented directly.

Two, it might provide better and faster lookups.

Three, I suspect (don't quote me) that it might be easier to manage
them in the datasource if it can be guaranteed that they all share the
same basic source for their information.

Additionally, I figure if they go over to being directly
datasource-backed, I can start to write them up to modify the database
directly in their methods, a la EJB.  Which I want to learn more about
:)

One possible hiccup that occurs to me is the one base measure -- a
gram.  This would now have to be gotten from each datasource as a
datasource-specific quantity - this isn't fatal, but it is a bit
grotty.

=3D=3D=3D=3D=3D
Web-databases
=3D=3D=3D=3D=3D
I've looked at the calorieking website, and it doesn't look like they
expose any webservices for their databases, which means we're going to
have to write a screen scraping library for it.  I'm not a big fan of
that, but if it's what we have to do, so be it.  I'll start piecing
together something that will allow me to test it directly, without
having to bolt it into our current setup.

Also, what was the other site?  I want to check their site out, too.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.