Thread: I receieved an example of Rekall script

I receieved an example of Rekall script

From
Typing80wpm@aol.com
Date:
I had posted and emailed various places, to find a tutorial or example of how to write my own scripts in Rekall to access Postgresql.  Someone was kind enough to send me the following example, so I want to share it with anyone who may be interested in using Rekall as a front end to Postgresql.
 
I strongly feel that Rekall developers should assemble and make available such tutorials, because it will help to promote the popularity of Rekall and increase the user base.  There are many people like me, who are clever enough to learn from good examples and become productive, but are lost without examples and tutorials.
 
If I can become even somewhat productive with Rekall, I will certainly purchase the product and/or support ... its not that I want everything for free. I just want to know that I am purchasing something I make work and get some use out of.
 
If anyone else has some Rekall examples they would like to share, please email me directly, if you like, typing80wpm (at) aol (dot) com
 
Or, if you know of an email listserve or a forum where I could find such help, examples, tutorials, code snippets.
 
Thanks for your help!
 
>
> What I REALLY NEED right now is a working example of a REKALL python
> script which could do SQL pass through to the Postgres engine which is now
> working on the P2P. I really like Rekall, but it is frustrating that there
> are  no examples.
>

Here's a little examle. Its the "onclick" event function for a button,
and it loads a choice control with surnames taken from a table called users:

def eventFunc(button) :

    # Load the RekallPYDBI module. This provides direct access to the database
    # begind Rekall
    #
    import RekallPYDBI

    # Get a "cursor". We do this by connecting to the database: the
    # (button,"") arguments just connect to the database that the form is
    # running in.
    #
    cursor = RekallPYDBI.connect (button, '').cursor()

    # Execute a query. This only gets people whose ages are 21 or above.
    # This is the important bit, we are accessing the database directly.
    #
    cursor.execute ("select surname from users where age >= ?", [21])

    # Assemble a list of surnames. Create an empty list, then for each record
    # returned by the cursor, append the first item in the record (the
    # surname) to the list
    #
    values = []
    for record in cursor.fetchall() :
        values.append (record[0])

    # Load the choice control. This is for a control called "people" in the
    # same block as the button (".." moves from the button up into its block,
    # then "people" find the people choice control.
    #
    choice = button.getNamedCtrl('../people')
    choice.setValues (values)



The key is getting the "cursor". Once you have a cursor you can do inserts,
updates and deletes, like

cursor.execute("delete from customers where balance < 0.01")

cursor.execute("insert into users (firstname, surname) values (?, ?)",
['john', 'smith'])

cursor.execute("update users set firstname = ? where surname = ?", ['john',
'smith'])


Python DB-API 2.0 oddity (was: I receieved an example of Rekall script)

From
Karsten Hilbert
Date:
A note on what I think is a strangeness in the Python DB-API 2.0.
Please correct me if I am wrong.

(Note that I am not trying to throw off the OP but simply use
his example to point out an oddity about that API. The point
is to make sure it *is* an oddity so I can raise it with the
appropriate forum, eg the Python community.)

Observe the following notes by someone learning the DB-API:

> # Get a "cursor". We do this by connecting to the database: the
> # (button,"") arguments just connect to the database that the form  is
> # running in.
> #
> cursor =  RekallPYDBI.connect (button, '').cursor()
So far so good... But - getting a cursor without knowing the
SELECT query the results of which it stands for ?

> # Execute a  query. This only gets people whose ages are 21 or above.
> # This  is the important bit, we are accessing the database directly.
> #
> cursor.execute ("select surname from users where age >=  ?", [21])
Ah, the query is set *after* getting a cursor for it - seems
odd, but hey, as long as it's set before retrieving rows ...

> The key is getting the "cursor". Once you have a cursor  you can do inserts,
> updates and deletes, like
Huh ? Pardon me ? Doing inserts, updates and deletes via a
cursor ? The PostgreSQL documentation clearly says that the
<query> part of a cursor definition must be a SELECT:

http://www.postgresql.org/docs/7.4/static/sql-declare.html

(I am well aware that SELECT queries may have side
effects that change data in the backend such as in
"select add_new_customer()" etc.)

The sequence of using a cursor in the Python DB-API is as
follows:

 conn = dbapi.connect(...)
 curs = conn.cursor()
 curs.execute('[select | insert | update | delete] ...')
 print curs.fetch(no_of_rows)    # if query was a select

This seems mighty odd to me. Should it not be:

 # get connection
 conn = dbapi.connect(...)
 # select w/o cursor so we get entire result set right away
 rows = conn.execute('select ...', use_cursor = False)
 # select w/ cursor so we can traverse result set as needed
 curs = conn.execute('select ...'), use_cursor = True)
 rows = curs.fetch(no_of_rows=25)
 # insert
 conn.execute('insert ...')
 # update
 conn.execute('update ...')
 # delete
 conn.execute('delete ...')

Wondering,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

Re: Python DB-API 2.0 oddity (was: I receieved an example of

From
Marco Colombo
Date:
On Mon, 2005-05-02 at 11:56 +0200, Karsten Hilbert wrote:
> A note on what I think is a strangeness in the Python DB-API 2.0.
> Please correct me if I am wrong.
>
> (Note that I am not trying to throw off the OP but simply use
> his example to point out an oddity about that API. The point
> is to make sure it *is* an oddity so I can raise it with the
> appropriate forum, eg the Python community.)
>
> Observe the following notes by someone learning the DB-API:
>
> > # Get a "cursor". We do this by connecting to the database: the
> > # (button,"") arguments just connect to the database that the form  is
> > # running in.
> > #
> > cursor =  RekallPYDBI.connect (button, '').cursor()
> So far so good... But - getting a cursor without knowing the
> SELECT query the results of which it stands for ?

AFAIK cursors are not limited to SELECTs.

> > # Execute a  query. This only gets people whose ages are 21 or above.
> > # This  is the important bit, we are accessing the database directly.
> > #
> > cursor.execute ("select surname from users where age >=  ?", [21])
> Ah, the query is set *after* getting a cursor for it - seems
> odd, but hey, as long as it's set before retrieving rows ...
>
> > The key is getting the "cursor". Once you have a cursor  you can do inserts,
> > updates and deletes, like
> Huh ? Pardon me ? Doing inserts, updates and deletes via a
> cursor ? The PostgreSQL documentation clearly says that the
> <query> part of a cursor definition must be a SELECT:
>
> http://www.postgresql.org/docs/7.4/static/sql-declare.html

But what makes you think that Python DBI was designed to be PostgreSQL
specific?

http://www.python.org/peps/pep-0249.html

.cursor()

            Return a new Cursor Object using the connection.  If the
            database does not provide a direct cursor concept, the
            module will have to emulate cursors using other means to
            the extent needed by this specification.

It's up to the module implementation to use real SQL cursors when
possible. AFAIK, it's not done automagically for PostgreSQL.
In practice, DBI cursor objects and SQL cursors have little in common
in the PostgreSQL drivers I'm aware of (PygreSQL and psycopg). A DBI
cursor is just an handle to execute SQL commands.

.TM.
--
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                      Colombo@ESI.it


Re: Python DB-API 2.0 oddity (was: I receieved an example of

From
Marco Colombo
Date:
On Mon, 2005-05-02 at 11:56 +0200, Karsten Hilbert wrote:

> > The key is getting the "cursor". Once you have a cursor  you can do inserts,
> > updates and deletes, like
> Huh ? Pardon me ? Doing inserts, updates and deletes via a
> cursor ? The PostgreSQL documentation clearly says that the
> <query> part of a cursor definition must be a SELECT:
>
> http://www.postgresql.org/docs/7.4/static/sql-declare.html
>
> (I am well aware that SELECT queries may have side
> effects that change data in the backend such as in
> "select add_new_customer()" etc.)
>

BTW, look at this page (with the Oracle driver):

http://www.zope.org/Members/matt/dco2/dco2doc

  cursor.execute("INSERT INTO TEST (name, id) VALUES (:name, :id)",
                  name="Matt Kromer", id="1")

I believe there are databases that allow you to send SQL statements (any
kind, not only SELECTs) only in a cursor (either implicit or explicit),
hence the name for the cursor object.

.TM.
--
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                      Colombo@ESI.it