Why database modules are incomplete

[Dave Cole]

>>>>> "Paul" == Paul Boddie <paul at boddie.net> writes:

>>  Boy, would I ever like to be able to complete my modules...

Paul> Isn't that true for most of us? ;-)

It is the universal constant.

Paul> Understood. But as I pointed out in the thread from which the
Paul> message you respond to came from, the usefulness of your module
Paul> in your business, and your reliance on that module, should be
Paul> seen as guarantees that you take its development seriously. It
Paul> is for this reason that I took exception to Mr Wilson's
Paul> "Maverick" accusations.

It is not enough to be a serious user yourself.  When things start to
go wrong in the server (resource shortages, ...), you get to see all
sorts of things happen at the interface layer.

Only by having lots of users can you build a reputation of providing a
"serious" module.  Given that almost no-one ever tells me that they
have used the module (successfully or otherwise), it is a bit hard to
know just how serious a module I have developed.

Paul> Actually, I think I did try your Sybase module out about a year
Paul> ago or so, by the way. What held me back there was, I think, the
Paul> lack of certain required libraries with my Sybase system, but I
Paul> may have got it working in the end. Sorry if I never
Paul> communicated that!

That is OK - you are free to use whatever module you like.  I have
just added one more module to the list of possible solutions to your
problem.  There is also no obligation to tell me about your experience
with my module.

Paul> An interesting point emerges here, though. The process of module
Paul> discovery can be somewhat stressful. It's quite likely that many
Paul> people give up "too easily" while building extensions, for
Paul> example, and move on to the next candidate module. In my Sybase
Paul> adventures, I tried your module and ctsybase first; ctsybase was
Paul> easiest to get working but lacked support for bind/bound
Paul> variables. Since I can't abide working without them, I moved
Paul> over to mxODBC, even though the effort in getting ODBC working
Paul> can be significant, but at that point I had the possibility of
Paul> choosing other database systems and was satisfied enough not to
Paul> do any more evaluation of other modules.

When a module does not just compile and work it is very annoying.  You
tend to question the competence of the developer.  It is only by
getting feedback from people who fail to have the module "just work"
that the installation can be made more robust.

I have some ideas about how to make it easier to get my module working
- maybe for the next release.

Paul> I certainly accept this. It can be disheartening to release
Paul> something which seems interesting and exciting to oneself, only
Paul> to be met with near silence in response.

I can see people downloading the module - there have been 182 unique
IP addresses which downloaded the Sybase-0.2x module.  I have no idea
how many them even compiled the module.

Paul> I think obscure bugs are the things that worry people most
Paul> particularly about database modules. ;-)

Yeah.  If you are simply passing the SQL and parameters from the
Python code directly to the database API then there is not a lot of
scope for changing the meaning of the SQL and parameters on the way
through.  About the only thing I can see going wrong is incorrect
binding of binary values...

>> 2- People who experience problems do not bother contacting me.
>> 
>> Although it would be nice to think that option 1 is true, I suspect
>> that option 2 is closer to the truth.

Paul> There's another possibility: people may experience problems but
Paul> may not have your level of skill to diagnose or investigate
Paul> them. I accept that this isn't a good enough excuse when, in
Paul> this case, there is someone taking responsibility for the
Paul> module, but then in periods of a maintainer not having enough
Paul> time to work on the module whilst doing paid work, development
Paul> and fixes are understandably delayed. Whilst it seems harsh and
Paul> ungrateful, developers are often impatient creatures who only
Paul> report problems when they happen and frequently give up quickly,
Paul> choosing the path of least resistance (to the next candidate
Paul> module).

I think that is what I was trying to say.

Paul> Of course, and no-one can or should be blamed for this. One big
Paul> problem in the development of database modules in particular is
Paul> the rarity of developers motivated enough and with enough
Paul> resources to help people like you out.

Never a truer word spoken.

Paul> Not many people in the past have had access (or the inclination
Paul> for ideological or other reasons to access) Sybase database
Paul> systems whilst developing interfaces to the native libraries.
Paul> Indeed, even those who have access to such systems may find
Paul> libraries and headers missing.

True.

Paul> What this means in general is that some projects are likely to
Paul> be driven by a single developer without "peers". A good way to
Paul> make this situation more bearable for such developers and for
Paul> the community would definitely go down well.

Now you have your work cut out for you... :-)

- Dave

-- 
http://www.object-craft.com.au