Recent changes to bugs

SkunkWeb 3.4.0 failed in building on Federa core 4

Anonymous — Sat, 17 Sep 2005 01:50:35 -0000

Firstly, it can not build mod_skunkweb on apache 2.0.54.
Secondly, it has following error while make.
gcc -g -O2 swpython.c -o swpython
swpython.c: In function main:
swpython.c:17: warning: incompatible implicit
declaration of built-in function alloca
This probably coz by configure it with
--without-mod_skunkweb option to lose some files.
ps: the build script is:
./configure --with-apxs=/usr/local/apache2/bin/
--without-mod_skunkweb;make;make install

PyDO: MySQL commit/rollback methods are no-ops?!

Matthew Bogosian — Tue, 09 Aug 2005 18:31:20 -0000

The following is cut from PyDO/mysqlconn.py:

#methods not needed for mysql
...
def commit(self): pass
def rollback(self): pass

Huh? MySQL's InnoDB tables support transactions and MySQL
silently accepts and ignores BEGIN, COMMIT and ROLLBACK
statements for other table implementations. MySQLdb's connection
objects even have mthods for begin(), commit() and rollback().

PyDO should probably be aware and make use of these:

# I'm guessing here...
def commit(self):
self.conn.commit()
def rollback(self):
self.conn.rollback()

See my other bug about BEGIN statements for starting transactions.

PyDO: interface is inconsistent

Matthew Bogosian — Tue, 09 Aug 2005 18:19:30 -0000

PyDO's subclassing requirements seem to be riddled with
inconsistencies. For example, the auto_increment attribute is
lowercase_with_underscores, whereas most attributes (e.g.,
connectionAlias) are camelCase. Another example is that the unique
attribute requires a list whereas the fields attribute must be a tuple of
tuples.

This of course is not serious, but it is annoying for OCD sufferers
like myself.... ;-)

PyDO: MySQL's commit/rollback implementation lacks BEGIN

Matthew Bogosian — Tue, 09 Aug 2005 18:08:31 -0000

Since PyDO subclasses do not have begin() methods to correspond
to their commit() and rollback() methods, it seems as if
transactionality would be unavailable without additional voodoo
magic depending on the database implementation. For example,
most MySQL installations turn on auto-committing by default, so
that if a transaction is not explicitly started with a BEGIN statement,
everything is committed immediately upon execution.

Since (in many hosting environments) many users do not have
control of the database's global configuration, they must (wherever
possible) perform the same configuration on a per-connection basis.
For example, with MySQL, one can turn off the above behavior and
use implied transactions (without the BEGIN statement) by first
issuing a SET AUTOCOMMIT = 0 statement. Doing so using PyDO
is kind of clunky:

db = DBIGetConnection('db_name')
db.execute('SET AUTOCOMMIT = 0')

This of course would only work if 'db_name' represented a MySQL
database (which in my case, it doesn't necessarily).

I see (potentially) two (real) fixes to this problem. The first is to
include the above clunky behavior (by default) in the creation of
MySQL connections (this only addresses the MySQL issue, and I
do not know the behaviors of other DBs).

The second is to incude a begin() method in PyDO classes, which
for some DBs could be a no-op, and for others (e.g., MySQL) could
issue whatever statement was appropriate for starting a transaction.

I admit I am unfamiliar with the implementation of PyDO and I do not
know if either is even possible given the current architecture. I just
thought I would bring this up since it has been an issue for me in the
past.

PyDO: abstraction is not complete

Matthew Bogosian — Tue, 09 Aug 2005 17:54:04 -0000

I don't know if there's a way around this, but it seems to me that
PyDO's abstraction, although good, is not complete since class
definitions are still often dependent on the underlying database
implementation(s).

For example, let's say I have an application where I want to let my
users choose the supporting DB application (e.g., MySQL, Oracle,
PostreSQL, etc.). Depending on the DB choice, my PyDO classes
may be quite different:

} - - - - - - - - - - - - - - - - %< - - - - - - - - - - - - - - - - {

from PyDO import *

...

if db == 'MySQL':
class Foo(PyDO):
connectionAlias = 'some_db'
table = 'some_table'
fields = \ (
('id', 'bigint(20) unsigned'),
('data', 'varchar(255)'),
)
auto_increment = { 'id': 'id' }
unique = [ 'id' ]
elif db == 'Oracle':
class Foo(PyDO):
connectionAlias = 'some_db'
table = 'SOME_TABLE'
fields = \ (
('ID', 'NUMBER'),
('DATA', 'VARCHAR2(255)'),
)
sequence = { 'ID': 'SOME_TABLE_ID_SEQ' }
unique = [ 'ID' ]
elif db == ...:
class Foo(PyDo):
...

} - - - - - - - - - - - - - - - - >% - - - - - - - - - - - - - - - - {

Perhaps PyDO could provide some mechanism for wrapping or
insulating developers from doing the if ... elif ... in this case? I don't
have any specific ideas, other than perhaps registering
implementations with DB aliases? The way I do it right now is kind
of clunky:

} - - - - - - - - - - - - - - - - %< - - - - - - - - - - - - - - - - {

# File: my_modules/data/storage.py

_DB_NAME = 'some_db'

_DB_CLASS_NAMES = \ (
'SomeClass1',
'SomeClass2',
)

# Figure out the lowercase db type (e.g., 'mysql', 'oracle', etc.)
_db_type =
PyDO.PyDBI._aliasToConnArgs[_DB_NAME].split(':')[1].lower()

# Try to import my_modules/data/DB_TYPE.py
_db_mod = __import__('my_modules.data.%s' % _db_type,
globals(), locals(), ( ' ', ))

# Import all the relevant classes into this module's namespace
for _db_class_name in _DB_CLASS_NAMES:
exec '%(db_mod)s = _db_mod.%(db_mod)s' % { 'db_mod':
_db_class_name }

} - - - - - - - - - - - - - - - - >% - - - - - - - - - - - - - - - - {

In the above, my_modules/data/mysql.py would have definitions for
the MySQL versions of the classes, my_modules/data/oracle.py
would have the Oracle definitions, etc., but modules using these
classes would only import my_modules.data.storage after defining
the 'some_db' connection alias without worrying about which
implementation was being used.

Clearly some thought would be needed for a more elegant/generic/
scalable solution (if one exists). Some tricks may have to be used
for differences between different driver layers for the same
underlying database implementation (e.g., psychopg vs. pypgsql).

I don't know, this is just a thought as it is something with which I've
wrestled a couple of times now with no clear idea on the Right Way
to do it.

SkunkWeb doesn't work with Cygwin

Jarosław Zabiełło — Sat, 24 Jul 2004 15:25:24 -0000

I am afraid SkunkWeb 3.4b5 does NOT work with Cygwin
:(.

C:\opt\cygwin\bin\python2.3.exe (480): *** unable to
remap C:\opt\cygwin\bin\cygssl-0.9.7.dl
0x800000) != 0x810000
3 [main] python 3324 sync_with_child: child
480(0x678) died before initialization with
131 [main] python 3324 sync_with_child: *** child
state child loading dlls
SkunkWeb exited abnormally! -- check the error log file
for details

logs:

[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR: File
"skunkweb", line 97, in ?
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR:
SkunkWeb.Server.start()
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR: File
"/usr/local/skunk/lib/SkunkWeb/Server.py", line 159, in
start
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR: svr.
mainloop()
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR: File
"/usr/local/skunk/lib/pylibs/ProcessMgr/ProcessMgr.py",
line 126, in mainloop
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR: if os.
fork():
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR:
[Sat, 24 Jul 2004 15:15:47 GMT] [4016] ERROR:
exceptions.OSError: [Errno 11] Resource temporarily
unavailable

pydo mysql getAutoIncrement

engelbert gruber — Mon, 28 Jun 2004 13:57:03 -0000

tells::

File "PyDO/mysqlconn.py", line 76, in getAutoIncrement
return self.conn._db.insert_id()

proably because _db is no longer defined::

return self.conn.insert_id()

works

.inc and .pyinc files accessible from URL (3.4b5)

Matthew Bogosian — Tue, 06 Jan 2004 23:51:41 -0000

I can download my .inc and .pyinc files from a URL!

If I create:

DOCROOT/foo.inc
DOCROOT/foo.pyinc

And then go to:

http://localhost/foo.inc
http://localhost/foo.pyinc

I can download the files (they are of types
"text/x-stml-include" and "text/x-stml-python-include"
respectively).

According to the docs (and several articles), these
files should generate 404s if attempts are made to
access them through a URL (which seems like a pretty
good idea to me).

I don't know if it makes a difference, but I'm
accessing my SkunkWeb server through Apache 1.39 +
mod_skunkweb (I turned off SkunkWeb's own HTTP handler).

usertracking cookie not properly refreshed

Jeroen van Dongen — Thu, 04 Dec 2003 22:15:11 -0000

If the expiring time of the cookie for the usertracking
module is set to something short (e.g. 2 hours), and
the lifetime of your browser session extends the
lifetime of the cookie, a new cookie is not given out,
but an error occurs instead.

Granted, short-living tracking cookies are not very
usefull outside a development environment, but a la ...

Authenticator.py problems

Brian Olsen — Tue, 02 Dec 2003 20:40:14 -0000

When using Authenticator.py with the swpasswd utility,
it overwrites any present data in the authentication file.