I note that right now SQLObject passes data in to the database as part
of the query string. This is a Bad Thing for multiple reasons:
- Having data be part of the query string prevents the database from
caching the SQL parse tree. This can be very substantial: benchmarking
my company's application (not based on SQLObject, but at that time using
string substitution for database access) once showed that our database
was spending 50% of its time doing soft parses!
- Having data be part of the query string prevents values with very
large string representations from being used. Some databases have limits
on the maximum query string (Oracle does with certainty) which are much,
much lower than the longest data elements possible. Using bound
variables would allow very large data elements to be inserted via SQLObject.
- Having data be part of the query strings means that bugs in the
quoting algorithm used can lead to SQL injection attacks.
- An Oracle backend (from what I hear) might be easier to implement once
quoting concerns are addressed (by passing data values in as raw objects
and thus not needing to quote them at all).
Admittedly, reworking the code to function this way might be a little
bit tricky, but I believe it should be doable without making things
excessively ugly by storing the data elements to be referenced in a dict
encapsulated into a class containing both the data dict and the
constructed string with an overridden __mod__ which combines the dicts
as it substitutes the string elements appropriately. Unique naming for
the dictionary elements would also need to be addressed, but shouldn't
be excessively hard; likewise for handling for the various
parameter-specification formats allowed by the DB-API specification.
I don't have enough time to implement such a thing in full, but I would
be more than glad to put together a proof-of-concept initial
implementation should there be interest on the part of the upstream
maintainers in potentially doing a final implementation should the proof
of concept be sufficiently compelling. Yea? Nay?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
sqlobject-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
