deciding to use this database engine?

[abused by speech recognition]

I know when I ran open source projects I hated to hear this kind
questions but is there sufficient life with this database that if I
use it in a project, I'll regret using it in a couple of years?

The project is a series of tools related to diabetic meal and blood
sugar management. I absolutely detest SQL because it takes me as long
figure out SQLs it does to write a fair body of code and I am using
speech recognition. From the description in the documentation (very
nice by the way) it looks like it should be an order of magnitude
easier to work with this database then it would SQL.

In the first part of project, meal planning, it will be 99% reading
with a small amount of changes as people create or update recipes. I
think it's safe to assume that if someone is creating a recipe,
they'll be the only one writing that particular recipe.

Data logging what you ate and your blood sugar levels (I'm serving
type twos only right now) will involve much more writing again, one
person, one record but there'll be multiple people writing different
records at the same time. This will be web-based and initially, the
code will be running in a CGI-based web framework I created for simple
projects like this[1].

see any reasons why I should or shouldn't use buzhug based on my
application?

--- eric

[1] I use my own framework because it's the only one I can use easily.
Every other framework excludes disabled developers using speech
recognition.

[Pierre Quentel]

On 16 juin, 08:28, abused by speech recognition <e...@harvee.org>
wrote:

> I know when I ran open source projects I hated to hear this kind
> questions but is there sufficient life with this database that if I
> use it in a project, I'll regret using it in a couple of years?

Hi,

It depends on what you call a couple of years ;-) I didn't change
anything in buzhug for some time, just because I don't see anything to
change and no one reports bugs or requests new features. But I still
keep an eye on the group and am ready to write patches and release
versions if enough users request it

>
> The project is a series of tools related to diabetic meal and blood
> sugar management. I absolutely detest SQL because it takes me as long
> figure out SQLs it does to write a fair body of code and I am using
> speech recognition. From the description in the documentation (very
> nice by the way) it looks like it should be an order of magnitude
> easier to work with this database then it would SQL.
>
> In the first part of project, meal planning, it will be 99% reading
> with a small amount of changes as people create or update recipes. I
> think it's safe to assume that if someone is creating a recipe,
> they'll be the only one writing that particular recipe.
>
> Data logging what you ate and your blood sugar levels (I'm serving
> type twos only right now) will involve much more writing again, one
> person, one record but there'll be multiple people writing different
> records at the same time. This will be web-based and initially, the
> code will be running in a CGI-based web framework I created for simple
> projects like this[1].
>
> see any reasons why I should or shouldn't use buzhug based on my
> application?

buzhug uses a simple version control mechanism to report concurrency
problem for web applications, this is explained in detail in the
documentation. I see no reason why buzhug would not be a good choice
for your application, and you have the pleasure of using the nice
Python syntax instead of SQL...
>
> --- eric

Best regards,
Pierre