cronometer-development — Development Related Discussion for CRONOMETER

[Cronometer-development] Design of food/datasource

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

I know that this is mainly my fault -- I should have examined this in
the redesign, but in adding the functionality to distinguish identical
foods, I have come across a flaw in the design of the food/datasource
model.

The issue, as I see it, is that the datasource is too tightly coupled
to HOW the food is stored in the backing store, especially w/r.to the
writeable foods.  What needs to happen is that all writes to the food
tables need to be handled internally to the food (EJB-style -- I
wonder if a future rewrite could use the Spring framework?) and the
datasource just needs to handle the aggregation and searching of the
contents of the store.

So, the upshot of this is, I need to tear the guts out of the
datasources and make them more...  robust in order to make the
duplicate food problem go away, and render this whole bag of code more
maintainable over the long term.

I'm also a bit skeptical about the use of reflection to map nutrients
-- it leads to a relatively small set of code in the child classes, to
be sure, but I think I can accomplish the same with a hashmap and a
string array, and let the code be more extensible over the long term.=20
With permission, I'll go in and make that change, as well.

Back on track :)
--
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Commit log text and JIRA bugs

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

Just as a matter of policy, can we agree to put any bug IDs that are
affected by a commit in the CVS log statment?  If we do that, JIRA
will pick them up automatically and make a note of them in the bug's
log, allowing us to keep a handle on what we've done that affects
them.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] Final application directory structure

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

On 6/13/05, Aaron Davidson <dav...@cs...> wrote:
> Chris Rose wrote:
>=20
> >We need, as I see it, two things:  One, we need to aggregate all of
> >our dependencies into ${CRON_HOME}/lib and two, we need to have some
> >kind of automatically-generated launcher for these things.  All of
> >this then needs to go in a tgz, a zip, and an installer.  An rpm would
> >be nice, too, if possible.  Plus whatever macs use (dmg?), which is
> >probably a higher priority than rpm, come to think of it :)
> >
> >
> Leave the Mac & Windows launchers to me. I already have an exe launcher
> made for windows, and it's easy for me to rebuild if anything changes.
> On the mac, the distribution is *inside* the application, which I know
> sounds weird, but on Mac OS X an application is a special type of
> folder, with some metadata in an xml file.

Alrighty.  However, in order to make them more integrated into the
maven build process, those need to be scripted somehow.  I assume you
have an ant build.xml that does the grotty, shitty work for you?=20
Assuming that's the case, can you toss that into CVS, and send
whatever support jars/executables are needed to me so that I can put
them into the repository?

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] Final application directory structure

[Aaron D. <dav...@cs...>]

Chris Rose wrote:

>We need, as I see it, two things:  One, we need to aggregate all of
>our dependencies into ${CRON_HOME}/lib and two, we need to have some
>kind of automatically-generated launcher for these things.  All of
>this then needs to go in a tgz, a zip, and an installer.  An rpm would
>be nice, too, if possible.  Plus whatever macs use (dmg?), which is
>probably a higher priority than rpm, come to think of it :)
>  
>
Leave the Mac & Windows launchers to me. I already have an exe launcher 
made for windows, and it's easy for me to rebuild if anything changes.  
On the mac, the distribution is *inside* the application, which I know 
sounds weird, but on Mac OS X an application is a special type of 
folder, with some metadata in an xml file.

[Cronometer-development] Final application directory structure

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

With all of the runtime dependencies we're using here, we've got to
have some way of making this app run as painlessly as possible for the
end-user.

Right now, I've got user setup bits put in, although not assembled
into a usable, simple whole yet.  Possibly over this week.

However, the eventual installation is going to be a bit rougher.

We need, as I see it, two things:  One, we need to aggregate all of
our dependencies into ${CRON_HOME}/lib and two, we need to have some
kind of automatically-generated launcher for these things.  All of
this then needs to go in a tgz, a zip, and an installer.  An rpm would
be nice, too, if possible.  Plus whatever macs use (dmg?), which is
probably a higher priority than rpm, come to think of it :)

How close are we, in general?  At this point it looks to me like we
don't have any dependencies on the command line tool for database
loading, and I've removed the requirement to pre-initialize the
database schema, so I think the setup issues and the user model are
it, for now.  Some UI hackery would be good, too, but I think that if
we buckle down a bit over the week (time permitting) or two coming up,
we can probably see something we can ship Real Soon Now.

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] JIRA it is!

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

http://offby1.no-ip.org:8080/browse/CRO
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Migration to bugzilla

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

sf.net's bug system just pissed me off, so the local server it is.

I might just get JIRA up and running here, if I have the horsepower
for it.  Tough call, though, since I already have an apache instance
up and running.  It might be overkill.  For two devs, though, it
should be enough.

I think that we should make getting some kind of J2EE/LAMP server
hosting from the CR society the first thing on our list, if there's
nothing more pressing.

Bug tracker URL to follow later today.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] USDA in-app importing

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

I have committed preliminary (VERY) functionality for importing the
USDA foodDB into the app.  Since I'm no swing guru, it's ugly as sin,
andmore relevantly, needs some serious working over to make the
threading work well -- right now, it just suspends waiting for the
return, which kills the rest of the UI.  Not so good, that.

But, the functionality is there, which is the important part.  It
doesn't currently write to the DB, since that might be dangerous.=20
Still, in the next little while, when I nail down the new schema, I'll
blow away the USDA DB and throw this into it.  I'll have to add some
checking for table existence, and re-creation thereof.  Although the
code is pretty tightly coupled to the current structure, I think we
might be able to make a bit of use of this to be a generic updater,
too.

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Menu construction

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

I've been doing some thinking about how the UI elements are
constructed, and I'm having a small problem with the menubar setup,
which might actually not be solvable with the current class-less model
we use for it.

Essentially, I want some mechanism for construction of Action
subclasses to do the work of the menu items.  This is mainly for
dynamic menu purposes -- as I see it right now, there's no capability
within SpazMenu for enablement/disablement and/or modification of
display name, or even flat-out hiding.  These are important abilities
in a menu, in my view.

This came to me while I was beginning to plot out the integration of
the USDA importer into the application.  I am going to bolt it on so
that we can provide the app to people sans database, and then they can
import the USDA stuff themselves.  There's a couple of ways to do it,
one of which would ideally be an on-startup wizard, but in the interim
we can provide a File->Import USDA Foods menu item that will look up
the file we need, download it, extract it, and import it.  I'll be
working up preliminary functionality for that tonight, and maybe
saturday I can polish it up enough that it'll work.  In that vein, can
our installer -- whatever mechanism we use, eventually -- ensure that
the final location of the food DB (in the program root?  User home?)
and the user DB (same questions, although easier to answer) are
properly A) created on the filesystem, and B) written to the
properties file.

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Re: Notes on Maven conversion

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

One more thing:  For a list of jars that we can get at without having
to do anything special at all, use http://www.ibiblio.org/maven/

The directory goes:=20
/maven/${groupId}/${type}s/${artifactId}-${version}.${type} for the
tags in the <dependency> element in the project.xml, so this tag:

<dependency>
=09<groupId>httpunit</groupId>
=09<artifactId>httpunit</artifactId>
=09<version>1.6</version>
=09<type>jar</type>
=09<url>http://httpunit.sourceforge.net/</url>
</dependency>

would translate into /maven/httpunit/jars/httpunit-1.6.jar

We have a private repository, too, and I'll eventually set one up on
sourceforge so I don't have to host it.

On 5/29/05, Chris Rose <of...@gm...> wrote:
> A few things are required to make Maven work the way you want it to:
>=20
> 1) install Maven 1.0.2 from http://maven.apache.org/start/download.html=
=20
> 2) Configure maven as described here: http://maven.apache.org/start/insta=
ll.html=20
> 3) Ideally at this point you should have the latest project.xml and
> project.properties for CRONOMETER from CVS.  This will allow you to
> get the latest and greatest jar files we work with.  To do so,
> assuming the above is true, just run "maven java:compile" from the
> base of the project (${eclipse.workspace}/CRONOMETER)
> 4) To configure Eclipse properly, you'll need the mevenIDE plugin,
> from the update site at
> http://mevenide.codehaus.org/release/eclipse/update/site.xml (Use the
> usual Eclipse IDE update installation for that)
> 5) Once MevenIDE is installed, you'll want to set the Maven nature on
> the CRONOMETER project:  right-click on the project, from that menu
> select "Maven -> Add Maven Nature"
> 6) Delete all of the libraries from the classpath of your project
> (and, in fact, delete the jars from the lib directory)
> 7) Your classpath will now need to be updated.  A "Pom Synchronizer"
> view should have appeared.  If it didn't, from the same Maven menu as
> #5, select "Synchronize".  In the Pom Synchronizer, right click on all
> the libraries it's showing (which should be a lot) and select "add to
> .classpath".  You will need to set a classpath variable MAVEN_REPO to
> $HOME/.maven/repository for this to work.
>=20
> To add new libraries, I will be setting up an ftp drop for them
> eventually, but right now just mail them to me, along with the snipped
> of the project.xml that refers to them, and I'll set them up. Once you
> do that, just drop them in your own repository (in $MAVEN_REPO) and
> you can use them easily.
>=20
> Chris R.
> =3D=3D=3D=3D=3D=3D
> Not to be taken literally, internally, or seriously.
>=20


--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Notes on Maven conversion

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

A few things are required to make Maven work the way you want it to:

1) install Maven 1.0.2 from http://maven.apache.org/start/download.html
2) Configure maven as described here: http://maven.apache.org/start/install=
.html
3) Ideally at this point you should have the latest project.xml and
project.properties for CRONOMETER from CVS.  This will allow you to
get the latest and greatest jar files we work with.  To do so,
assuming the above is true, just run "maven java:compile" from the
base of the project (${eclipse.workspace}/CRONOMETER)
4) To configure Eclipse properly, you'll need the mevenIDE plugin,
from the update site at
http://mevenide.codehaus.org/release/eclipse/update/site.xml (Use the
usual Eclipse IDE update installation for that)
5) Once MevenIDE is installed, you'll want to set the Maven nature on
the CRONOMETER project:  right-click on the project, from that menu
select "Maven -> Add Maven Nature"
6) Delete all of the libraries from the classpath of your project
(and, in fact, delete the jars from the lib directory)
7) Your classpath will now need to be updated.  A "Pom Synchronizer"
view should have appeared.  If it didn't, from the same Maven menu as
#5, select "Synchronize".  In the Pom Synchronizer, right click on all
the libraries it's showing (which should be a lot) and select "add to
.classpath".  You will need to set a classpath variable MAVEN_REPO to
$HOME/.maven/repository for this to work.

To add new libraries, I will be setting up an ftp drop for them
eventually, but right now just mail them to me, along with the snipped
of the project.xml that refers to them, and I'll set them up. Once you
do that, just drop them in your own repository (in $MAVEN_REPO) and
you can use them easily.

Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] speed

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

I think that's a good idea, at least it sounds like one.  Since we're
dealing with an embedded DB, this should be reasonably workable.

One other thing we should do, as we move towards a beta, is design ye
olde website.  SF will host it, assuming we have simple needs, and we
can move it later if we get more complicated.

On 5/28/05, Aaron Davidson <ada...@po...> wrote:
> Did a little snooping on the slow speed -- It's definately just the
> food loading. It gets worse and worse as you add more and more foods to
> the daily list. It has to load each one from the database every time it
> is needed. Adding a food to the day forces all foods in that day to be
> reloaded from scratch.
>=20
> We could cache loaded foods in a WeakHashMap, and always check it
> before loading. Just need to make sure it is *always* checked first, so
> that read/write stale cache conflicts don't occur. What do you think?
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005=20
> _______________________________________________
> Cronometer-development mailing list
> Cro...@li...=20
> https://lists.sourceforge.net/lists/listinfo/cronometer-development=20
>=20


--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] speed

[Aaron D. <ada...@po...>]

Did a little snooping on the slow speed -- It's definately just the 
food loading. It gets worse and worse as you add more and more foods to 
the daily list. It has to load each one from the database every time it 
is needed. Adding a food to the day forces all foods in that day to be 
reloaded from scratch.

We could cache loaded foods in a WeakHashMap, and always check it 
before loading. Just need to make sure it is *always* checked first, so 
that read/write stale cache conflicts don't occur. What do you think?

[Cronometer-development] Centralized configuration

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

I've just centralized all of the configuration information for the app
-- it's all kept in a single properties file in the classpath root,
and accessed via CRONConfiguration instead of individual property
sets.

Furthermore, CRONConfiguration now writes user properties -- whatever
the user wants to configure, et al -- to a user property file in
$HOME/cron.properties, which allows us to have user customization.

The only exception to this is the logging properties, which remain
separate, since they are not app-related.  Also, note that to set up
logging in any tests you want to run, just call
CRONOMETER.configureLogging() and it will set it up for you.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] Latest news, design questions

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

So I've recently rewritten the model for Datasources to allow them to
be loaded by reflection from the Datasources object -- it reads a
properties file with classnames, factory method names, and string
parameters (that's the only restriction) and then calls the method to
return the datasource.  The only one that is required to succeed is
the user DS, other than that it's open.

NutritionData.com is partially in place.  It loads food groups, and is
beginning to acquire the bits needed to search for foods.  I'm close
on that one, I think.  I have the general outline of what I want to
do, now it just remains to be seen if I can do it.

The design issue I have is with the "Create New Food" use case.  Right
now, we allow it to be created as coming from any given source -- be
it nd.com, USDA...  The thing is, it won't keep that info - It will be
set to "My Foods" no matter what, since that's the only food
datasource that is allowed to change at all.  I know the dialog is
generic, so maybe that combo box could be disabled when it's used for
a new food?  I'm thinking maybe that box should be a label, instead --
that field will never be changeable in there.  Then, when a food is
edited from a non-mutable source, it can be changed to reflect the new
source.

I'm still working through some UI ideas in my head right now.  I can
feel that there's things I'd like to do, but the ideas aren't gelling.
 I only know that I don't want to do too close an imitation of the
food tool you're already using.  Which is, I realize, not necessarily
your call on it.  Naturally where it comes to design, I have to bow to
your preferences :)  Still, I think it might pay to sit down and have
a UI design session of some kind sometime soon.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] DB Schema extension

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

On 5/12/05, Aaron Davidson <ada...@po...> wrote:
> Funny, I was JUST about to post my thoughts for handling recipes.
>=20
> Basically, I was thinking that a Recipe, a collection of food measures,
> generates a new Food Item. The only thing that is unique about a recipe
> food is that there are extra tables for that food item, detailing the
> recipe. When the recipe is edited, the Food's nutrient values are
> recomputed from the ingredients. I think this fits in nicely with what
> you outline below. In fact, maybe you already were thinking exactly
> this, but It wasn't clear from your post.
>=20
> I think I would just get rid of the RECIPE table -- instead we have a
> FOOD entry. Instructions can be stored as a food comment (which we
> haven't implemented yet of course).
>=20
> RECIPE_INGREDIENT_MAPPING (
>         INTEGER Food_ID FOREIGN KEY
>         INTEGER Weight_ID FOREIGN KEY
>         REAL Quantity
> )
>=20
> > And a modification to the Weight table giving it a unique Weight_ID
> > primary key for reference purposes, maintaining the foreign key
> > relation into Food.  This relation means that a particular unit of
> > weight is sufficient to identify a Food in the recipe, as well as make
> > for more readable recipes on the client side.

The only problem with this is that, while it does help keep a recipe a
conceptual food, it also makes it harder to add things like
descriptions and preparation instructions -- which, while not strictly
in the purview of this app, would be nice.  Maybe make it a three-step
link -- keep the recipe table, but it'll lose the name -- that will go
into food, and it will instead have a foreign key into the food table
to link it there.  I say this because recipies, while sort of foodly,
are really not the same thing.

Also, where are we going to calculate these values?  I guess we can do
it on loading of the recipe -- but just imagine the number of DB calls
we'll have!  Also, what about the food editor for a recipe?  Suppose
you modify the sum of the caloric values?  What happens to the
sub-foods?

Realistically, the more I think about it, the more I believe that we
would be best off keeping a separate table of recipes, and then in the
daily list, programmatically merging them, but keeping them separate
for purposes of additions -- maybe make recipes a new data source?=20
Something like it, anyway.
=20
> We should make this change to the CONSUMED table as well. Right now it
> just stores the gram amount, but it might be friendlier to also store
> the Measure as well (but it's safest to keep grams in case the Measure
> gets deleted, it can still function). Also we should not forget to
> change
> the table names to MEASURE and SERVING, to minimize confusion down the
> road.

I concur.

> Another use-case I was thinking about that makes me slightly
> uncomfortable. Right now, I might click on USDA, search and add a
> banana. Then a few weeks from now, imagine I accidentally add a banana
> again from USDA, instead of from MyFoods. This adds banana again to
> MyFoods, so now if I search in MyFoods, I'll see two banana entries
> show up.
>
> A typical user will select one of the two and delete one. Now what do
> we do then? We don't want the information for their Servings to be
> lost. Actually, this is an issue for any deletion of a Food. If they've
> consumed that food in the past, deleting it from MyFoods will throw off
> all their past records.
>=20
> I'm not sure what we should do here....ideas?

I was thinking about this, too.

Perhaps we should add a "visible" tag to the foods table?

The more we add to this, the more certain I become that my original
idea of mixing the My Foods and USDA into one table will cause more
trouble than it's worth.  The personalized foods, while similar, have
so many more operations to support that it's not really worth it --
and then we can optimize the hell out of the USDA one with indices all
over the place...

Since the datasource abstracts that anyway, changes to the underlying
schema are not important to the UI -- but I think maybe we need to do
lunch next week and go over these.  What say you to Monday?  Tomorrow,
even, but I know you guys do builds on friday, right?

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] DB Schema extension

[Aaron D. <ada...@po...>]

Funny, I was JUST about to post my thoughts for handling recipes.

Basically, I was thinking that a Recipe, a collection of food measures, 
generates a new Food Item. The only thing that is unique about a recipe 
food is that there are extra tables for that food item, detailing the 
recipe. When the recipe is edited, the Food's nutrient values are 
recomputed from the ingredients. I think this fits in nicely with what 
you outline below. In fact, maybe you already were thinking exactly 
this, but It wasn't clear from your post.

I think I would just get rid of the RECIPE table -- instead we have a 
FOOD entry. Instructions can be stored as a food comment (which we 
haven't implemented yet of course).

RECIPE_INGREDIENT_MAPPING (
	INTEGER Food_ID FOREIGN KEY
	INTEGER Weight_ID FOREIGN KEY
	REAL Quantity
)

> And a modification to the Weight table giving it a unique Weight_ID
> primary key for reference purposes, maintaining the foreign key
> relation into Food.  This relation means that a particular unit of
> weight is sufficient to identify a Food in the recipe, as well as make
> for more readable recipes on the client side.

We should make this change to the CONSUMED table as well. Right now it
just stores the gram amount, but it might be friendlier to also store
the Measure as well (but it's safest to keep grams in case the Measure
gets deleted, it can still function). Also we should not forget to 
change
the table names to MEASURE and SERVING, to minimize confusion down the 
road.

Another use-case I was thinking about that makes me slightly 
uncomfortable. Right now, I might click on USDA, search and add a 
banana. Then a few weeks from now, imagine I accidentally add a banana 
again from USDA, instead of from MyFoods. This adds banana again to 
MyFoods, so now if I search in MyFoods, I'll see two banana entries 
show up.

A typical user will select one of the two and delete one. Now what do 
we do then? We don't want the information for their Servings to be 
lost. Actually, this is an issue for any deletion of a Food. If they've 
consumed that food in the past, deleting it from MyFoods will throw off 
all their past records.

I'm not sure what we should do here....ideas?

[Cronometer-development] DB Schema extension

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

I'll have to look into the how of this, and the if, but I think we
need to look at improving the foreign key relations we have --
cascading delete would be a good start.  Specifically, when a FOOD is
deleted, all the dependent tables shouldn't prevent the delete (as
they currently do), but rather should cascade delete -- why keep them
around?

On the other hand, when it comes to recipes (this thinking came about
as a consequence of coming up with a schema for recipes, which I'll be
detailing below) I think we want to prevent deletion of foods that are
in use that way.

So I'll look into HSQLDB and see if it does cascading deletes, or not.
 Unless you disagree?

So here's the rough schema I see for the recipes (I'm not being strict
SQL -- types are logical ones, not real ones):

RECIPE (
=09INTEGER Recipe_ID PRIMARY KEY
=09STRING RecipeName NOT NULL
=09BIGSTRING Instructions
)

RECIPE_INGREDIENT_MAPPING (
=09INTEGER Recipe_ID FOREIGN KEY
=09INTEGER Weight_ID FOREIGN KEY
=09REAL Quantity
)

And a modification to the Weight table giving it a unique Weight_ID
primary key for reference purposes, maintaining the foreign key
relation into Food.  This relation means that a particular unit of
weight is sufficient to identify a Food in the recipe, as well as make
for more readable recipes on the client side.

The potential issue with this is that all foods have the "gram" weight
-- this might require some hors-DB sleight of hand to make work.=20
Maybe recipes can only work with named measures?  That's not too
unreasonable.

Additional tools we will want in the app for recipe support is
conversion of volumes to weights for storage.  We may want to create
some unit mappings, or alternately store an extra column in the
recipe_ingredient_mapping table to indicate a conversion unit?
=09
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

[Cronometer-development] database troubles

[Aaron D. <ada...@po...>]

Since the last check-in, I can no longer start the program. I get an 
error connecting to the database.

It's probably not the code changes -- when I try to load my database in 
DatabaseManager, it looks empty, even though the files are 10MB+

I think maybe last time I was working on things, maybe it crashed in a 
bad state. Could I maybe get a fresh database copy from you?

I think I know what my final nutrient organization is going to be now, 
so I'd like to do some database work putting the final touches on the 
nutrient situation.

Cheers,
Aaron

[Cronometer-development] diffSource

[Aaron D. <ada...@po...>]

Right now it can't create new foods as it complains in diffSource() 
that the source is the same. I think this was intended to prevent 
adding a food that already exists in the mutable foods.

How should we handle this case? Should I modify diffSource() to 
actually query the source for the prior existence of the food, or 
should I work higher up the call hierarchy to avoid calling 
diffSource() when adding a new food?

Re: [Cronometer-development] Measure/Serving in the database

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

I think you're right, all told.  I was thinking about it, and there's
really no need to worry about it -- the specific Food class can
provide those services as needed, since it will be tied to whatever it
is passed with.

Should work out okay.

I've dropped a note to both nutritiondata and calorieking asking about
web service interfaces, I'm not holding my breath, but it would make
things a lot easier if they got onboard.

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] Measure/Serving in the database

[Aaron D. <ada...@po...>]

On Apr 27, 2005, at 8:31 PM, Chris Rose wrote:

> 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.

I suppose...

> 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.

Why? How?

> 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.

i.e, a Measure for a Food both must be from the same datasource?

> 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.

Yeah, hmmm. It's kind of a universal Measure, and we don't want a gram 
Measure
entry for every single Food, since it's a huge waste.

> 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.

Yeah, I think all of these ones would be faking it through the forms.

> Also, what was the other site?  I want to check their site out, too.

nutritiondata.com

[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.

[Cronometer-development] Flash of insight

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

I was thinking over the problems I had with associating the Food and
Measure and Serving objects with their DB equivalents, and I realized
what the problem is -- I need to replace all of them with interfaces
and just create them out of custom implementations in the
IFoodDatasource implementations.

So, that's what I'm going to do, before things become more coupled.

Barring objections, of course.  But I do think that this will allow
your UI end to concern itself just with IFoodDatasource and
Food/Measure/Serving instead of having to explicitly call all these
creator et al methods.
--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.

Re: [Cronometer-development] Idea for database schema and model for eater &c

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

One more thing...  What should we allow searching by?  I need methods
to do all of that relatively simply, without exposing underlying data
formats.

--=20
Chris R.
=3D=3D=3D=3D=3D=3D
Not to be taken literally, internally, or seriously.