Create a set of farm-budgets-data editing functions

[qjhart]

Currently, there are many near replicated materials, units, and operations. We need to get these organized in a better fashion. My proposal is this: We expect for now, that we will be doing these changes in the postgres database. So, I say we create postgres functions to make these modifications.
If we do that correctly, these may be used later in the editor. For example:

create function replace_unit(old varchar(12),new varchar(12)) 
RETURNS varchar(12)
AS $$
update farm_budget_data.production set unit=$2 where unit=$1;
update farm_budget_data.operation set unit=$2 where unit=$1;
update farm_budget_data.material set unit=$2 where unit=$1;
update farm_budget_data.price set unit=$2 where unit=$1;
delete from unit where unit=$1;
select $2;
$$ LANGUAGE SQL;

Replaces a certain unit with another. After export, all the data is updated.

The problem I see however, is that currently, our db is super simple, and we could use a bunch of other backends (like sqlite or even lovefield) and in that case, maybe it's better to move these to JS functions. I suppose we could do both, where we write JS functions, but then import those into the postgres db to use interactively.

[jrmerz]

Seems like there are two issues here; do we move to a simpler database solution as well as how do we want to preform edits.

I would say moving databases to something like sqlite isn't a bad idea if others want to load the db locally. Obviously the single file structure of sqlite makes it very easy to setup and use. As for lovefield, I am not acquainted with that db and would have to investigate.

As for edit functions, I think this is the line where a DB guys says put them in the database and a programmer says outside. I am ok with db if we place the functions in their own schema file and document with comments. Otherwise I would proly say JS.

[qjhart]

I think my idea of sharing functions is goofy. The Lovefield API is way different than the normal SQL, so we pick one or the other. Since postgres has a nice console, I think I'll just write in that. Lovefield looks interesting, but I don't see a method to easily pre-fetch a complete db onto a client, (that's a client obsevaration)