Mailing List Archive


Back to the month index Back to the list index
Joseph Bueno (jbueno@magic.fr)
Thu, 15 Apr 1999 21:58:11 +0200 

Message-ID: <371644D3.2400A188@magic.fr>
Date: Thu, 15 Apr 1999 21:58:11 +0200
From: Joseph Bueno <jbueno@magic.fr>
Subject: Re: more wishes

Raimi wrote:
>
> Hello!
>
> I thought about my ideas again and I missed some:
>
> - I possibility to select just the lenght of text-based fields, not the
> text itself.
> - Do some more math on integer fields:
> - add/multiply/... alls values of a column for example or
> - add all lengths of a text-column
>
> Bambi: What do you think about stuff like that?
>
> _ __
> | ) | "What do you get if you * ** |
> |\aimund multiply 6 by 9?" * * * |
> | | **** *
> \_/acob * *** O
>
> **** Remember: 21 is just half the truth ****

Hello,

Before expanding too mush the wish list, just one remark:

The reason why I use msql is that it is small (only one
daemon and a few utilities) and *fast* for simple queries.
Also, it is quite reliable (msql2d deamon crashes from
time to time but we have never lost any data in past two
years).
These features make it a good backend for a Web server.

Before considering adding new features to msql, you should
evaluate the impact on performance and reliability since it
is, at least for me, the main reason for choosing msql.

There are other RDBMs with more features (postgresql for
example in Open Source world) that already implement most
of what appears in your wish list but are slower and bigger
than msql. I don't think that becoming a clone of these
tools is the right way for msql.

Of course, this is just my opinion; I don't want to open
a "wish war". 

-- 
Joseph Bueno
jbueno@magic.fr
From james_harrell@mindspring.com  Thu Apr 15 16:55:11 1999
Received: from gatech.gatech.edu (root@gatech.edu [130.207.244.244])
	by services.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA23202
	for <msql-list@services.bunyip.com>; Thu, 15 Apr 1999 16:55:10 -0400 (EDT)
Received: from thing1.btc.gatech.edu (thing1.btc.gatech.edu [199.77.147.147])
	by gatech.gatech.edu (8.9.0/8.9.0) with SMTP id QAA06118
	for <msql-list@services.bunyip.com>; Thu, 15 Apr 1999 16:55:09 -0400 (EDT)
Received: from jharrell by thing1.btc.gatech.edu (SMI-8.6/SMI-SVR4)
	id QAA08020; Thu, 15 Apr 1999 16:55:02 -0400
Message-Id: <199904152055.QAA08020@thing1.btc.gatech.edu>
X-Sender: james_harrell@mail.mindspring.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 
Date: Thu, 15 Apr 1999 16:55:16 -0400
To: Multiple recipients of list <msql-list@services.bunyip.com>
From: "James E. Harrell, Jr" <james_harrell@mindspring.com>
Subject: Re: more wishes...
In-Reply-To: <371644D3.2400A188@magic.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Seems that every day or so, people are asking to add feature x or y... What
this comes down to, is that we really don't have much of an idea of the
requirements tree Hughes is working with... every month or so for the last
few months, a bug fix / requirements change / feature addition has been
implemented and released. While this turn around is excellent, from the
outside it seems a little haphazard...

Perhaps a design paradyme shift is in order here- I'd much rather wait 3 or
even 6 months for the next version with all of the new features combined
and (hopefully) debugged than get a new feature once a month. Better yet if
I know in advance what all those new features are going to be! Feature
creap seems to be getting a little out of hand! If I had a production
server that required patching once a month, I would find the maintenance to
be almost unmanagable! On the other hand, if I had a list of all known
features and deficiencies of the current release, I could write my programs
around those knowing that they may not be addressed for 6 months.

Given the stability of the current release (secondhand knowledge, I don't
have a production server running yet), I would think it wise to take a step
back and enter a requirements definition phase for the next major release.
(ok, *maybe* minor release)- Once the requirements are completed, freeze
them. 

Maybe even give the user base a good look at the requirements prior to
freeze- and give them a method of requesting requirements additions. This
way, the next release would have a know implementation that is expected.
Might take six months to get there, but so be it. It's controlled.

On the other hand, bug fix releases are always welcome. But when a feature
addition is combined with a bug fix, certain conflicts exist. If my
programs are not affected by the bug, I won't upgrade the server! But a
common answer to most questions in this group seems to be "Upgrade to
Version x.x; it has the features and bug fixes you need" - this should
*only* be the case with respect to bug fixes, and never the case with
respect to features. In my opinion, the feature additions should be
reserved for major releases! Thus, the answer to bug questions should be,
upgrade to patch version xxx, while answers to *feature* questions should
be "wait for version XXX".

>From a wider scope, it would be nice to have an idea as to the expected
future development path. I remember years ago (in some 1.x version
discussion) hearing that msql will *never* support things like atomic table
operations (arithmatic or otherwise), stored functions, transaction
support, record locking, security management, etc. But the more development
I see with this product, the more realistic those expectations become.
Better said, with a product so well desinged and supported, the user base
expectations are increasing! What I'd like to see, is a requirements tree-
if some day we expect to see row locking in a HugheSQL-Pro, add the
requirement but assign it to version 5.0! And for those that only want the
lightweight version, maybe there will be product diversion in the future...

As always, Bambi, keep up the tremendously good work. But don't let us
corner you into feature additions weekly! Hear our requests, prioritize
them, assign them importance levels; and put them into a future
requirements document(s) that shows us when you expect to implement them.
And give us a new features in six months or even a year! (but keep the bug
fixes comming!)

Just my $0.03 worth.

... james
From bambi@Hughes.com.au  Thu Apr 15 18:41:59 1999
Received: from sonic.fan.net.au (sonic.fan.net.au [203.20.92.3])
	by services.bunyip.com (8.8.5/8.8.5) with ESMTP id SAA24510
	for <msql-list@services.bunyip.com>; Thu, 15 Apr 1999 18:41:57 -0400 (EDT)
Received: from fawn.Hughes.com.au (dialup-nas1-02.gc.fan.net.au [203.23.134.3])
	by sonic.fan.net.au (8.9.1/8.9.1) with ESMTP id IAA17405;
	Fri, 16 Apr 1999 08:41:52 +1000 (EST)
Received: from localhost (Received: from localhost (hughes@localhost)
	by fawn.Hughes.com.au (8.8.7/8.8.5) with SMTP id IAA04885;
	Fri, 16 Apr 1999 08:41:49 +1000 (EST)
X-Authentication-Warning: fawn.Hughes.com.au: hughes owned process doing -bs
Date: Fri, 16 Apr 1999 08:41:49 +1000 (EST)
From: "David J. Hughes" <bambi@Hughes.com.au>
To: Raimi <raimi@cs.tu-berlin.de>
cc: Multiple recipients of list <msql-list@services.bunyip.com>
Subject: Re: Wishlist, if you don't mind
In-Reply-To: <Pine.SOL.3.91.990415162924.6687A-100000@cerberus.cs.tu-berlin.de>
Message-ID: <Pine.BSF.3.96.990416083948.362J-100000@fawn.Hughes.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 15 Apr 1999, Raimi wrote:

> Hello Bambi, hello List!

Hi, and I don't mind your wish list t all.

> - A dummy statement one can use as a 'ping' on the database.
>   I hava a persistent FastCGI that has a mSQL server handle open for
>   quite a long time. I'd like to have something I can query the db
>   to check if it's still there (if the server dies I don't get    
>   an error unless I read or write to the socket).

Yup.  Good idea.  Hadn't thought of that one.

> - Simple math on integer fields.
>   Atomic like the sequences. Can be useful i.e. if you want to remember how
>   many bytes you sent some client over the web or just want to have some 
>   counters.

Yup. Math in updates is on the list.

> - Read Sequences without incrementing them.
>   For even simpler counters.

hmmm, OK.  Don't see the point but it's an easy add.

> Well...
> I won't bother you with lite enhancements if you consider these wishes :)

Please.  Send it all through.  The more input we can get from you guys,
the real users of the software, the better we can make the products for
you.

Bambi
...