Thx for the review of my idea. For what it's worth, Here is a sample
of my code which uses 'eval' to create the DAL code:
The input args are the db object, a db.tbl object, and a string of
comma
separated DAL-type field specifiers (eg. "db.myTbl.person,
db.myTbl.dog...")
---
def Select(db, tbl, selectStr):
if (selectStr == '') or (selectStr == 'ALL'):
rows = db().select(tbl.ALL)
else:
selectFldStrs = selectStr.split(',')
selectFlds = [eval(fldstr) for fldstr in selectFldStrs]
rows = db().select(*selectFlds)
return rows.response
---
On Jul 10, 6:19 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> There is no eval in DAL. Actually b) is safer. The overhead is
> negligible compared to the database IO times. You are doing the right
> thing
>
> On Jul 10, 1:55 am, rb <rbspg...@gmail.com> wrote:
>
> > Thx for the speedy reply. Here's another question:
>
> > 3) Because I'm doing a thick client, it creates db queries (SQL CRUD)
> > which need to be communicated back to the controller which must query
> > the db. The two ways to do this are:
>
> > a) use a SQL statement within a executesql command, or
>
> > b) create a DAL row selection criteria string and a column selection
> > criteria string, send them back to the controller which feeds them
> > through a python eval statement within a DAL function.
>
> > It is always pointed out that b) is dangerous because it's possible
> > for unintended string matter to get fed into the eval - which can reek
> > havoc. However only *my* strings from the client which I have
> > carefully massaged will ever be sent (e.g. I collect the column names
> > from the db beforehand and provide them to the db().select(<fieldnames-
> > here>) statement). Further, if I craft a SQL string then it too can
> > suffer from bad input. I just have to be extra careful when creating
> > the query strings.
>
> > However if I use a) then I lose all of the functionality provided by
> > the DAL. I've never been a fan of SQL and I'd like to avoid it in
> > favour of what the DAL can offer.
>
> > So I've implemented b) and it is working. My questions are:
>
> > i) am I missing the obvious? Is there a much simpler/better way to do
> > this?
> > ii) does the DAL add much overhead?
>
> > On Jul 9, 9:21 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > On Jul 9, 11:04 pm, rb <rbspg...@gmail.com> wrote:
>
> > > > Hi all,
>
> > > > I'm using Web2py to serve a wxPython thick client via XMLRPC. I'm
> > > > currently using SQLite (I like the zero db config ;-) and I have a few
> > > > questions:
>
> > > > 1) I have missed how to specify table constraints across several
> > > > fields (in SQLite). For example, in a table the primary key consists
> > > > of two fields - how do I specify that these two fields must comprise a
> > > > UNIQUE value? In other dbs I could use executesql to just give the SQL
> > > > commands, but SQLite (unless I'm mistaken) only allows table
> > > > constraints within the CREATE TABLE SQL command. So can this be done
> > > > in Web2py?
>
> > > You cannot create such constraint database side from
> > > web2py. Your options are:
> > > 1) enforce the constraint at the validators level
> > > 2) create the table outside web2py and set migrate=False
>
> > > > 2) I'm confused as to which models get run when a controller is
> > > > accessed. If I have db.py and uom.py models and I access the uom
> > > > controller, what happens? From stepping thru the debugger I saw db.py
> > > > get run first, then uom.py and then uom.py again (weird). I've
> > > > simplified things down to just one (db.py) file for now, but I'm
> > > > wondering if the infrastructure's intent is to run all model files
> > > > upon each and every controller access. Oh, my access of the controller
> > > > is via XMLRPC function (if that changes anything).
>
> > > All of them. Alphabetically. There has been some discussion on whether
> > > there should be exceptions to this rule. It would be easy to inplmenet
> > > but there was no consensus on whether an improvement was necessary.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
