How to contribute code?

Started by chi, May 17, 2009, 11:28:47 PM

Previous topic - Next topic

chi

Hello,



I am interested in newLISP for some time now. I read in the forum and studied several code examples. Now I intend to use newLISP for a small project at work.



For that, I have enhanced sqlite3.lsp a bit. I introduced the possibility of host variable bindings in the SQL statement of (sql3:sql) so that following would be possible now:
(sql3:sql "select * from fruits where name = ?;"  
     '("grapes"))


Now my questions are: is there any interest for such enhancement? If yes, how do I contribute the code? Should I provide the whole file sqlite3.lsp or a patch against 10.0.5?



Thanks in advance and



ciao,

chi :)

Lutz

#1
Is it something like this, you are doing?


(sql3:sql (format "select * from fruits where name = %s;" '("grapes")))

can you post the whole function?



Ps: the 'format' function can take it's parameters in a list

chi

#2
Quote from: "Lutz"Is it something like this, you are doing?


(sql3:sql (format "select * from fruits where name = %s;" '("grapes")))


No, as this statement would be easily attackable via SQL injection attack. To avoid that, I use the sqlite3_bind_*() calls to bind a value to a host variable mentioned in the SQL statement. That way, no injection attack is possible!


Quote from: "Lutz"can you post the whole function?


Of couse I could. It is a small additional internal function and a bit of additional code in (sql3:sql). And I have also extended (test-sqlite3) to test that feature, so it would be some pieces of code to post.



I could post a unified diff against 10.0.5 and my additions. Or I send a PM to you, with my sqlite3.lsp file attached.



Whatever you like!


Quote from: "Lutz"Ps: the 'format' function can take it's parameters in a list


Thank you for the hint, but (format) is not used here ;)



Ciao,

chi :)

Lutz

#3
Thanks for the information Chi. You can just email or pm me the file sqlite3.lsp and I include it in the upcoming 10.0.6 development release.



I assume you added an optional parameter to the 'sql3:sql' function so the function is used with or without extra variable binding? Thanks for adding a testing function too. You can send me the file to lutz at nuevatec dot com. Also let me know what name to add in the author line.

chi

#4
Quote from: "Lutz"Thanks for the information Chi. You can just email or pm me the file sqlite3.lsp and I include it in the upcoming 10.0.6 development release.




I sent you the extended file just a few moments before to the address you told me below. Thank you for considering to include my enhancement :-)


QuoteI assume you added an optional parameter to the 'sql3:sql' function so the function is used with or without extra variable binding?


You are right. I hope I did document it well, but if I need to improve the documentation, please let me know.



The optional parameter may be a normal list (if the host variables within the SQL statement are marked '?' only -- positional arguments), or a association list, if one choose to use the '?<number>', ':<name>', '@name' or '$name' style of host variable markup. In the second case, the parameter are not positional as they will be identified by the key part of an association, whereas the associations' value will be the value to be bound to the host variable.



If there is anything unclear. please let me know!


QuoteThanks for adding a testing function too. You can send me the file to lutz at nuevatec dot com. Also let me know what name to add in the author line.


Thank you for your nice language! :-)



Ciao,

chi :-)

Lutz

#5
From the new sqlite3.lsp test routines:


Quotetry to drop table fruits via SQL injection attack ... no luck, table was safe against SQL injection.


nice  :-)



I did some further testing (for memory leaks and 64-bit newLISP on OpenBSD and Mac OS X) and everything seems to be fine.



Thanks again a for this contribution.

chi

#6
Quote from: "Lutz"From the new sqlite3.lsp test routines:


Quotetry to drop table fruits via SQL injection attack ... no luck, table was safe against SQL injection.


nice  :-)


I am glad, you like it! :-)


QuoteI did some further testing (for memory leaks and 64-bit newLISP on OpenBSD and Mac OS X) and everything seems to be fine.



Thanks again a for this contribution.


You're welcome. I hope, I will have the opportunity to contribute some more in the future ...



Ciao,

chi :-)