i pushed up the results of some recent experimenting with
oldlibdrizzle. i realize it's old for a reason and i see the bell plan
includes it's replacement, but i wanted to share my thoughts/findings
asap in hopes of them being useful in the work towards
(new)libdrizzle:
the code can be found at:
http://bazaar.launchpad.net/~rwmcfa1/+junk/ldrizzle-proto
the README.txt file has a writeup.
http://bazaar.launchpad.net/~rwmcfa1/%2Bjunk/ldrizzle-proto/annotate/head%3A/README.txt
unfortunately i didn't start writing things down at the very beginning
so a lot of my stumbling (in trying to figure out how to use
oldlibdrizzle) wasn't documented. i tried to remember as much of it as
i could, but a decent amount of it is lost.
findings/ldrizzle-proto summary:
- there's a query object that encapsulates everything you need to
work with a query, results object (which was 1/2 of what you needed)
is gone. (see example in README.txt) with oldlibdrizzle it seems like
you have to have the original params around (sql string, etc.) to see
if query has completed, which is my least favorite things about
oldlibdrizzle.
- you don't have to call things in packet order to avoid errors.
if you don't care about columns and go directly to rows the columns
are skipped for you. if you don't finish out the fields in a row, the
same happens.
- the passing in pointers vs having them allocated for you stuff
is inconsistent/messy, i'd prefer to always pass in allocated
pointers/stack objects and have libdrizzle do as few mallocs as
possible as the default path. doing so would encourage use of stack
variables.
- naming needs quite a bit of cleanup, things should be made clean
OO-ish (in naming, encapsulation, parameter order) even though it's C
- everything should have a initialize and destroy that should be
called even if it's effectively a no-op.
- there's too much api; unless there's really strong reasons to
have two different ways to do something there probably shouldn't be
(buffered and non-buffered) if you look at how ldrizzle-proto works
everything is read on demand, assuming that is going to cause the
least amount of blocking & waiting for data when you want something
specific. having to do things one way if you use NON-BLOCKING and
another if you don't makes it complicated to start simple and build
up.
- i think the most important part of the client library is that
starting a query is non-blocking, by default. i'd bet that alone would
improve the performance of 95% of the uses of the client or at the
very least make it trivial for people to go from starting a query and
reading results to starting a query, doing some work, and then reading
the results. the biggest (related) performance gains i've seen people
achieve in the web arena come from starting the queries up front
(controller) and blocking only if the results aren't back by the time
the rendering thread (view) needs the data. the same principals apply
in many situations.
README.txt has lots more information. main.c is a pretty good example
of how i'd like to see things look/work.
all of this is obviously my opinion, thoughts/suggestions/feedback
solicited & appreciated...
best,
--
-rm
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
