Re: [Zope-dev] Using db_connections from Zope products
On 20 Jun 2001 11:25:01 -0500, Tom Brown wrote:
I would like to make an SQL query directly from python
code. Do I have to make a
ZSQL Method dynamically, or is there another way
without making the class database
dependent (i.e. Gadfly, PoPy, etc), utilizing an
existing db_con? Suppose I am using the ZPoPy DA and
have established a database connection externally.
How can I access this database
and submit a query from my own class?
I have a product which queries a specified database table from the
Product Class and both executes queries entirely in Python, and
builds ZSQL methods - populating them with std queries that can
then be customized.
You can directly use the database connection_id, but you will
probably want to insert :
import pdb; pdb.set_trace()
in your class and use the debugger as you go.
(I'll throw some probably bad code at you here - caveat emptor)
To start out, somewhere you will want to be able to specify the
connection id to use, such as:
TR
TD ALIGN=LEFT VALIGN=TOP
EMSTRONGConnection Id/STRONG/EM
/TD
TD ALIGN=LEFT VALIGN=TOP
SELECT NAME=connection_id
dtml-in SQLConnectionIDs
OPTION VALUE=dtml-sequence-item;
dtml-var sequence-key/OPTION
/dtml-in
/SELECT
/TD
/TR
and in your class, somewhere, something like this:
if REQUEST and REQUEST.has_key('connection_id'):
self.connection_id = REQUEST['connection_id']
To create the zsql methods, I first have to obtain some info:
def dbquery_handle(obj, connection_id):
Find and return the Zope database connector query method
database_type = ''
# Locate the Database Connector
try:
dbc=getattr(obj, connection_id)
database_type = dbc.database_type
except AttributeError:
raise AttributeError, (
The database connection em%s/em cannot be found. %
(connection_id))
# Prepare the Database Connector for a query
try: DB__=dbc()
except: raise 'Database Error', (
'%s is not connected to a database' % connection_id)
# Return the query method
return database_type, DB__.query
# There's got to be a more universal way to do this, but I don't
# know what it is
def tableexists(dbtype, dbq, tablename):
Query the database to see if the table exists
table_exists = []
if dbtype == 'MySQL':
try:
table_show_query = 'SHOW TABLES LIKE %s'
meta, table_exists = dbq(table_show_query % tablename, 1)
return table_exists
except :
pass
elif dbtype == 'Sybase':
try:
table_show_query = SELECT name FROM sysobjects \
WHERE id = object_id('%s')
meta, table_exists = dbq(table_show_query % tablename, 1)
return table_exists
except:
pass
return table_exists
Now..
# ZSQL Method creation
def create_zsqlmethods(self, id, connection_id, properties, maketable=0):
Create a series of Zope SQLMethods for this table
schema = []
tableschema = []
dbtype, dbquery = dbquery_handle(self, connection_id)
table_exists = tableexists(dbtype, dbquery, id)
... determine table schema from whatever, and instantiate the 'create'
SQL method:
create = SQL('createTable', title='',
connection_id=connection_id, arguments='',
template=table_create_query %(id, vars))
self._setObject('createTable', create)
...
and even create the SQL table if you need to:
if not table_exists and maketable:
self.createTable()
etc. etc.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] determining database manager type from z database connection?
On 3 May 2001 21:15:01 -0500, Andreas Heckel wrote: Kent Polk wrote: Is there a generic way to determine what 'brand' of database manager a Zope database connection is connected to by interrogating the connection object? dtml-in SQLConnectionIDs bID:/bdtml-var sequence-key btitle:/bdtml-var _.getitem(_['sequence-item']).title btype:/bdtml-var _.getitem(_['sequence-item']).database_type br /dtml-in database_type is the 'brand' of the Zope DA. If you are connectet to a PostgreSQL DB using ZPyGreSQLDA you get 'PyGreSQL'. Using ZPoPyDA it returns 'PoPy'. That's not exactly what you are looking for but I hope it helps. Actually, that is exactly what I was looking for. Thanks Much! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] determining database manager type from z database connection?
Is there a generic way to determine what 'brand' of database manager a Zope database connection is connected to by interrogating the connection object? I couldn't see anything in the source and I also walked a connection object using the debugger and couldn't locate any non-specific way to determine this, outside of triggering an exception and observing the exception contents... ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] getattr'ing proxy object's methods
On 13 Apr 2001 05:50:01 -0500, Dieter Maurer wrote: Kent Polk writes: I do not understand your goal precisely... However, the surrogate technique used in "CMFCore.DirectoryView.DirectoryView" may come near to your proxie objects. I played around with that and can't quite see how to map the proxy namespace onto the current one. I basically want to do a dtml-with in Python for the proxy clients. so that: dtml-in "getTable(...)" automatically adds the proxy's namespace, instead of having to do: dtml-with Proxy dtml-in "getTable(...)" where: def Proxy(self): """Return the proxy associated with this object""" return getattr(self, self.proxy_id) __call__ is never called in this context as it's trying to locate a method (that doesn't exist for the proxy client), so that's out. __of__, of course probably is the key, but I can't determine how to push the proxy's namespace onto the current call, much less be able to do anything with it since hasattr(self, self.proxy_id) returns 0 in the context of the __of__ call for the proxy client. I don't understand that one since self appears to be the correct object. I presume it has something to do with preventing recursion... I also tried adding the proxy's namespace to the client when created, which was quite interesting, but not quite what I had in mind. :^) That appears to leave me with just __bobo_traverse__, which can correctly locate the proxy object but I can't determine how I could use it to either directly call the proxy method (can't identify the method from inside __bobo_traverse__) or add the proxy's namespace in the context of __bobo_traverse__. Thanks! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] getattr'ing proxy object's methods
I have a product with a proxy class for building objects which manage data for other objects. The proxy clients locate their proxy via meta_type, similar to a sql connection_id and use acquisition to establish parameters for each call. I want to pass method calls made to the clients directly to the proxy, but in the context of the client. Right now, my clients have a method: def Proxy(self): """Return the proxy associated with this object""" return getattr(self, self.proxy_id) which is used in conjunction with dtml-with to establish the context: dtml-with Proxy dtml-in "getTable(project=Project, [...])" This works fine, however, I would like for the clients to automatically pass method calls that they don't have on to the proxy. __setattr__ is not called for the proxy clients because the final URL component specifies an acquired folder method, not the proxy client. I tried __bobo_traverse__, but again, the final URL component is passed as the argument instead of the method, so it's not clear exactly how __bobo_traverse__ could make sense out of what needs to be done, much less know what method was to have been called. Is there a proper way to call a proxy object's method in this context, directly in the product class, without using dtml-with? Thanks! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] More ZPatterns confusion
I have a persistent object class I'm trying to model in ZPatterns. --- MasterRack Class: A physical Master Rack is composed of 96 tubes of DNA, one tube per DNA sample, organized by families. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] 'REQUEST' lost on DTML rendering
I have a Product which works fine under Zope 2.1.6 but am having trouble moving it to 2.2.1 This product creates temporary instances of objects and then uses __bobo_traverse__ to traverse class operators specified in the URL which create the objects that are rendered via DTML methods. The very first time one of these objects is called (after tehe server is started), all works fine. With all subsequest calls, the DTML methods which render the results cannot locate the REQUEST dictionary anymore. My class methods can still see the REQUEST dictionary just fine with every call, but REQUEST apparently gets lost between when the bobo_traverse returns and when the DTML renderer starts. (and yes, this all worked fine prior to 2.2x :^) I'm stumped. How could the REQUEST object get passed the first time to the DTML renderer and never thereafter? What changed thereabouts? Thanks ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZServer and ftp port-1 data channel
It appears we still have a problem with ZServer's port 20 data
channel response behavior with the latest released Zope (Zope 2.2.1
(source release, python 1.5.2, linux2) and Active Mode ftp clients.
In particular, when you select the port-1 behavior, medusa can't
seem to bind to port 20 when port 21 command channel is specified.
"ftp_server.py" line 278:
if self.bind_local_minus_one:
cdc.bind (('', self.server.port - 1))
After verifying that self.server.port - 1 = 20, the current behavior
is that medusa simply hangs at the bind statement. If there was a
permissions problem my understanding (and experience) is that one
would receive:
socket.error: (13, 'Permission denied')
and not a process hang. Any idea why medusa simply hangs on the
attempted bind?
Thanks
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZServer and ftp port-1 data channel
On 26 Sep 2000 12:50:00 -0500, Shane Hathaway wrote: Here's what Sam Rushing told me regarding this issue. Shane Hathaway writes: I hear that you have found a way to get Medusa to use the correct port in active mode FTP. This could be a great benefit to the Zope community. Anything you have (diffs, modified files, or any kind of info) on the subject would be very much appreciated. (Sam writes:) [...] See the 'bind_local_minus_one' variable of the ftp_channel class. This should be checked into the medusa cvs, but I'll attach a copy as well. /* According to one expert, the very nature of the FTP protocol, * and it's multiple data-connections creates problems with * "rapid-fire" connections (transfering lots of files) causing * an eventual "Address already in use" error. As a result, this * nasty kludge retries ten times (once per second) if the * port being bound to is INPORT_ANY) */ This does not occur just during 'rapid-fire connections'. AFAI can tell, it *always* fails to bind to port 20 in this case. So I don't think this is the problem. Back to my question - Why would a port 20 bind() lock up the medusa process when absolutely no other transaction is transpiring on the server? Under what condidtions woudla bind() simply stop? - not fail, just fail to return from the bind() call? In other words, it's just bound to fail. A forking server can afford this sort of persistence, but in medusa I think it'd be overkill; I'd have to set up event timers, an object to maintain the retry state, etc [this alone it might add 50% to the size of ftp_server.py] --- I'd have to agree with Sam, it's just not worth the effort. So you are saying ZServer just isn't ever going to support Active ftp clients in the correct port-1 manner? If so, you might want to put a LARGE BANNER disclaimer about this matter as this makes ZServer unusable from most ftp clients that try to access it from behind standard a firewall. (And yes, on checking, it appears that the only OSes we could locate that come with a passive ftp client by default are the BSD's). ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] remote procedure calls to manage functions
On 10 Aug 2000 08:10:01 -0500, Jim Fulton wrote: Michel Pelletier wrote: Jim Fulton wrote: Michel Pelletier wrote: Also, ZClient is much faster i've found, probably due to the marshalling/unmarshalling necessary for xml-rpc. That's interesting..Hm. ZClient has to marshal. I suspect that xml-rpc wants some sort of optimization. I made a test script to make about 300 xmlrpc calls to various manage_ methods. I had to kill it after about a half-hour cuz it was takin so long. This sounds pretty fishy. Are you saying that you made less than 300 calls in half an hour? This doesn't seem right at all. I'm probably way off base here, but I use xml-rpc to transfer records to a Zope-based application from a bunch of Macs attached to ABI gene sequencers. The data is simple lists of lists and it *appears* to take about 2-3 seconds for the Macs to xml-encode and transfer the data as-is, but it takes typically *3 minutes* for the xmlrpc server to decode and rebuild the table data. This is for about 6000 records representing about 200k of text data (Sun Ultra 5 server). However, if I simply build a string representation of the table data, it takes about 3-4 seconds for the client to stringify, transfer the string data, and the server to reconstruct the table. Guess which method I use? The tests I ran using a SAX-based parser show it might parse and rebuild the data at least 50x faster than the current Python-only xmlrpclib. Now maybe something else is going on wrt manage* methods and xmlrpc, (I'm using external methods for managing the data transfer and am not storing the raw data in the Zope database), but my external methods-based calls rip along at a pretty good clip as long as I convert the data to a (few) string(s) before sending. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
