On 2014/09/24 15:06, Prakash Premkumar wrote:
Thanks a lot , Simon and Hick,
What I am looking for is , instead of iterating through the result which
sqlite provides and then form the respective objects and setting pointers,
is it possible to hack sqlite to fill in the objects this way.
I would like to prevent the extra iteration through the result set.
When the result row is formed in OP_ResultRow, we should be able to form
the structs and their links. Any pointers in this direction?
Hi Prakash,
I understand what and why you are trying to do to achieve this - but please let me suggest some alternatives, and explain why myself
(and everyone else seemingly) is urging you to not do it the way you are trying. Your code will only work with the current SQLite
amalgamation, it won't work ever again unless you update it every time a new version appears - which will be very tedious, and core
functionality might change, which means not only will you need to change your code, but at some point may even need to rethink your
entire strategy. How many times do you want to reinvent the wheel?
To be clear, new versions appear every other month more or less. Further to this, the amount of work you need to do to achieve what
you are trying is enormous, there is no quick "hack" for it, you have to meticulously adjust and inject code and test it into the
SQLite main engine - YES this is possible, but at what price? You are trying to do a job that requires 900% effort for a <1%
efficiency gain.
Further to this, the kind of tree-graph that you wish to build will only work for very specific kinds of queries, for instance
requirements such as columns need to be ordered in ascending complexity. If this is the only job this engine does and will not be
updated, then that does not matter so much.
Why not consider (as suggested by others) using the API as it is supposed to be used, for instance making a virtual table will do
this job exceedingly well, and really efficient. Just define a new table , write to it via a SELECT query and get from it the
structure or map or graph which you can very easily ascertain.
if the queries are going to be specific, you can even add SQL functions via the function adder API to systematically build tree
structure while the query is executing (though specific ordering will be required since the functions do not know at the time of
being called which specific row is being processed in the output and might be called more than once if it appears in the order-by
clause etc.).
Then, simply using the sqlite_step() and column value reading APIs will all do exactly what you want WHILE the query executes, no
need for extra loops... this is why they exist and no injected code could possibly be measurably faster. Why would you insist on
using another way?
Consider also that using ANY of the above suggested API methods will ensure you can plug-and-play any updated data engine from the
SQLite site in future (or past if you fancy testing) and capitalize on the improved performance or newer features without any
problems, without rewriting a single line of code. How is this not a 100 times better?
Please consider the alternates, save yourself a LOT of work.
Cheers!
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
