sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Custom Validator (unique-ness)

[Ian B. <ia...@co...>]

On Monday, September 8, 2003, at 12:43 PM, Sidnei da Silva wrote:
> Howdy,
>
> I was just looking at the new validator stuff, and trying to figure
> out how to do something:
>
> I need to have a constraint on one field that the field value is
> unique, but this field cannot be a primary key. So, I was thinking
> about giving it a Unique validator.
>
> Questions:
>
>   - It seems like the easier way to do this would be to use the
>   Wrapper validator, passing a callable that tests for uniqueness of a
>   column. Sounds right?
>
>   - Can I put the Unique class (that tests for uniqueness given a
>   column name) on the include/Validators.py module?

Unique is hard, because you can't test it in isolation.  You'd have to 
look at all the other rows, whether they are in memory or not.  It 
seems like the database would do this best.

Anyway, I don't think this is the best place for a validator, it's 
really best done in the database.  Is there a problem there?

Also, Validators.py is really part of another piece of (as-yet 
unreleased) software I'm writing, and include/Validators.py is (and 
will continue to be) a direct copy of that.  I'm not sure where the 
best place for a SQLObject-specific validator is.

   Ian

Re: [SQLObject] More transaction troubles

[Ian B. <ia...@co...>]

On Monday, September 8, 2003, at 07:03 AM, Randall Randall wrote:
>
> On Sunday, September 7, 2003, at 02:32 PM, Ian Bicking wrote:
>>>
>> Try CVS, I fixed a bunch of these yesterday.  Or 
>> http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2
>
> CVS doesn't seem to have changed yet, so I downloaded from colorstudy.
>
> In order to get it to install, I had to comment out this
> line in Col.py:
> #from include import Validator

Ah, I forgot the -d in cvs up -d for the script that makes that tarball.

> and change the setup.py packages line to
> packages=["SQLObject"], # , "SQLObject.include"],
> because there was no "include" module in the source,
> and nothing else in SQLObject appears to use Validator.
>
> Anyway, I haven't got the chance to fairly test whether
> transactions are working yet, because I'm using Python
> 2.2, and this SQLObject doesn't work with it.  I'll
> install 2.3 today and retest.

2.2 should be fine.  Are you having a problem with it?

   Ian

[SQLObject] Custom Validator (unique-ness)

[Sidnei da S. <si...@pl...>]

Howdy,

I was just looking at the new validator stuff, and trying to figure
out how to do something:

I need to have a constraint on one field that the field value is
unique, but this field cannot be a primary key. So, I was thinking
about giving it a Unique validator.

Questions:

  - It seems like the easier way to do this would be to use the
  Wrapper validator, passing a callable that tests for uniqueness of a
  column. Sounds right?

  - Can I put the Unique class (that tests for uniqueness given a
  column name) on the include/Validators.py module?

[]'s
-- 
Sidnei da Silva <si...@pl...>
dreamcatching :: making your dreams come true
http://dreamcatcher.homeunix.org

A feature is nothing more than a bug with seniority.
	-- Unknown source

Re: [SQLObject] More transaction troubles

[Randall R. <ra...@ra...>]

On Sunday, September 7, 2003, at 02:32 PM, Ian Bicking wrote:
>>
> Try CVS, I fixed a bunch of these yesterday.  Or 
> http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2

CVS doesn't seem to have changed yet, so I downloaded from colorstudy.

In order to get it to install, I had to comment out this
line in Col.py:
#from include import Validator

and change the setup.py packages line to
packages=["SQLObject"], # , "SQLObject.include"],
because there was no "include" module in the source,
and nothing else in SQLObject appears to use Validator.

Anyway, I haven't got the chance to fairly test whether
transactions are working yet, because I'm using Python
2.2, and this SQLObject doesn't work with it.  I'll
install 2.3 today and retest.

Thanks!

-- 
Randall Randall <ra...@ra...>
"When you advocate any government action, you must first
believe that violence is the best answer to the question
at hand." -- Allen Thornton

Re: [SQLObject] Non-integer primary keys

[Ian B. <ia...@co...>]

On Sunday, September 7, 2003, at 09:34 PM, Edmund Lian wrote:
> Ian Bicking wrote:
>
>> Changes to use non-integer primary keys have been made to CVS.
>
> Does this mean that MyObject(3) and MyObject(str(3)) no longer point 
> to different objects?

Unfortunately no, id columns still are treated specially, and there's 
no type coercion (though type coercion for other columns is now 
supported).

You could add something like:

     def _init(self, id, connection=None):
         id = str(id) # or int(id)
         SQLObject._init(self, id, connection)

Eventually the id column will use the same definition as other columns 
(so you can do automatic CREATE TABLE), and it'll get type coercion at 
the same time.

Easier to do would be to add something like:

     _idType = int

     def _init(self, id, connection=None):
         id = self._idType(id)
         ...

And then subclasses override this.  But I'll leave that for local 
modifications, since that's not an interface I want in the long term.

   Ian

Re: [SQLObject] Non-integer primary keys

[Edmund L. <el...@in...>]

Ian Bicking wrote:

> Changes to use non-integer primary keys have been made to CVS.

Does this mean that MyObject(3) and MyObject(str(3)) no longer point to 
different objects?

...Edmund.

Re: [SQLObject] SQLite fails for binaries

[Joshua R. <ad...@my...>]

Thanks. Your function has solved my problem.

Joshua Rothenberg
ad...@my...

[SQLObject] Non-integer primary keys

[Ian B. <ia...@co...>]

Changes to use non-integer primary keys have been made to CVS.  You 
have to generate the CREATE TABLE statement yourself at this point, and 
you have to supply IDs with all .new() (INSERT) commands.  The former 
will be resolved at some point when I also look at composite keys, but 
I'm going to set SQLObject enhancements aside for a while.  In a little 
while I'd like to release 0.5.

   Ian

Re: [SQLObject] SQLite fails for binaries

[Javier R. <jav...@Ho...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Rothenberg wrote:
>
> Well having made that change and tested various things extensively I
still have absolutely no clue what's going on, but now when I try to
read the img data it tells me "Error: Incorrect padding"... It looks
like, among other things, \n's are being turned into \\n's and not being
converted back properly (this is from using short strings instead of
full images; everything just seems to get garbled with big images).. And
it still works properly under PostgreSQL. I have no idea if the problem
is with my code, SQLObject's SQLite interface, PySQLite, or SQLite.
Although since it *does* work in other database systems its probably one
of the latter three.  Hasn't anyone had this problem before?
>
> Joshua Rothenberg

Joshua,
       I had the same problem some time ago. Make your getter function
use unQuote.


    def _get_stuff(self):
        def unQuote(val):
            # This list is from SQLObject/Converters.py.
            sqlStringReplace = [
                    ('\\', '\\\\'), ('\'', '\\\''), ('\000', '\\0'),
                    ('\b', '\\b'), ('\n', '\\n'), ('\r', '\\r'), ('\t',
'\\t') ]

            for final, original in sqlStringReplace:
                val = val.replace(original, final)

            return val

	# Using pickle instead of base64.
        # I don't think it makes a difference.
        from cPickle import loads
        return loads(unQuote(self._SO_get_valor()))

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/W8Vj8XQC840MeeoRAtP2AJ0QTtkjvr6m6+RWFaaaFKjRVg5XtQCeJvjx
EfLO6arjeiADPPnDdxBzvIk=
=DPch
-----END PGP SIGNATURE-----

Re: [SQLObject] More transaction troubles

[Ian B. <ia...@co...>]

On Sunday, September 7, 2003, at 05:00 AM, Randall Randall wrote:
> Okay I did that, and all the SQL looks sane.  It appears (from
> reading source) that Transaction() just passes through any
> commit() or rollback() it gets to psycopg (in this case), so
> there isn't any SQL generated from a rollback().
>
> I noticed that there's an "autoCommit" keyword for
> PostgresConnection(), and the comments imply that it should
> be turned on for transactions to work, but using it send
> a "pool" keyword to DBAPI.__init__(), and thence to
> DBConnection.__init__(), which doesn't expect it.
>
> Using the query method of Transaction(), I can see that
> commit() and rollback() are working okay; I think the
> reason that transactions didn't appear to work, above,
> is that SQLObject.new() just ignores the 'connection'
> keyword (and perhaps that's what it's supposed to do?).
>
> Setting _connection to the transaction in the class
> definition does seem to work, with the exception that
> a lot of stuff isn't defined for Transaction() that
> is supposed to be there for a _connection, like
> '_SO_selectOne', 'queryInsertID', etc.
>
Try CVS, I fixed a bunch of these yesterday.  Or 
http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2

   Ian

Re: [SQLObject] More transaction troubles

[Randall R. <ra...@ra...>]

On Saturday, September 6, 2003, at 02:07 PM, Ian Bicking wrote:

> On Saturday, September 6, 2003, at 03:58 AM, Randall Randall wrote:
>> Okay, so I got the current CVS, but transactions
>> still seem to not work. :)
>>
>> >>> r = Person.new(firstName='my', lastName='lastname', 
>> connection=trans)
>> >>> r.firstName = 'Bob'
>> >>> trans.commit()
>> >>> r.firstName = 'Billy'
>> >>> trans.rollback()
>> >>> print r.firstName
>> Billy
>
> Hmmm... that's odd.  Maybe you should give debug=1 to your original 
> connection and see what SQL is being sent.

Okay I did that, and all the SQL looks sane.  It appears (from
reading source) that Transaction() just passes through any
commit() or rollback() it gets to psycopg (in this case), so
there isn't any SQL generated from a rollback().

I noticed that there's an "autoCommit" keyword for
PostgresConnection(), and the comments imply that it should
be turned on for transactions to work, but using it send
a "pool" keyword to DBAPI.__init__(), and thence to
DBConnection.__init__(), which doesn't expect it.

Using the query method of Transaction(), I can see that
commit() and rollback() are working okay; I think the
reason that transactions didn't appear to work, above,
is that SQLObject.new() just ignores the 'connection'
keyword (and perhaps that's what it's supposed to do?).

Setting _connection to the transaction in the class
definition does seem to work, with the exception that
a lot of stuff isn't defined for Transaction() that
is supposed to be there for a _connection, like
'_SO_selectOne', 'queryInsertID', etc.

>> AttributeError: 'Transaction' object has no attribute '_SO_selectOne'
>
> Well, that's just a bug.   I'll look into it, I think I have a fix.  
> Of course it will go into CVS and you won't be able to check it for a 
> day.

Okay.

-- 
Randall Randall <ra...@ra...>
"You assist an evil system most effectively by obeying its orders and 
decrees." -- Mahatma Gandhi
"When you advocate any government action, you must first believe that 
violence is the best answer to the question at hand." -- Allen Thornton

Re: [SQLObject] SQLite fails for binaries

[Nicholas L. <nic...@pl...>]

On Sun, Sep 07, 2003 at 12:36:01AM -0400, Joshua Rothenberg wrote:
> images).. And it still works properly under PostgreSQL. I have no
> idea if the problem is with my code, SQLObject's SQLite interface,
> PySQLite, or SQLite. Although since it *does* work in other database
> systems its probably one of the latter three. Hasn't anyone had this
> problem before?

Have you tried encoding a file to text file, then running an insert from
the sqlite cmd-line tool? doing a select, then checking the two results.

Then the same with straight PySQLite, and no SQLO.

-- 
Nicholas Lee - nj.lee at plumtree.co dot nz, somewhere on the fish Maui caught.
gpg. 8072 4F86 EDCD 4FC1 18EF  5BDD 07B0 9597 6D58 D70C            icq. 1612865 

                         Quixotic Eccentricity

Re: [SQLObject] SQLite fails for binaries

[Ian B. <ia...@co...>]

On Saturday, September 6, 2003, at 11:36 PM, Joshua Rothenberg wrote:
> On Sat, 06 Sep 2003 22:55:31 -0400
> "Ian Bicking" <ia...@co...> wrote:
>
>> You should add:
>>
>>      def _set_content(self, value):
>>          self._SO_set_content(base64.encodestring(value))
>>      def _get_content(self):
>>          return base64.decodestring(self._SO_get_content())
>>
>> I'm not sure where the problem is, but this will make the whole thing
>> less error-prone.
>
> Well having made that change and tested various things extensively I 
> still have absolutely no clue what's going on, but now when I try to 
> read the img data it tells me "Error: Incorrect padding"... It looks 
> like, among other things, \n's are being turned into \\n's and not 
> being converted back properly (this is from using short strings 
> instead of full images; everything just seems to get garbled with big 
> images).. And it still works properly under PostgreSQL. I have no idea 
> if the problem is with my code, SQLObject's SQLite interface, 
> PySQLite, or SQLite.  Although since it *does* work in other database 
> systems its probably one of the latter three.  Hasn't anyone had this 
> problem before?

Hmm... you're right, SQLite is having some problem with quoting.  It 
seems backslash quoting just doesn't work in SQLite.  Perhaps because ' 
is quoted as '', and all other characters are allowed in the literal 
without quoting.  Except \0, which isn't allowed anywhere.  Hrm.  As a 
stop-gap, I think you can simply remove all the \n's from the 
base64-encoded string, and it's still valid base64 (whitespace is 
ignored).

I was hoping some of this database portability stuff could be avoided 
because database would all act the same (like string literal quoting).  
But maybe that's not the case.  Now... introduce portability in the 
Converters library, or use DBAPI parameters and let the driver do the 
quoting?

   Ian

Re: [SQLObject] SQLite fails for binaries

[Edmund L. <el...@in...>]

Joshua Rothenberg wrote:

> when I try to
> read the img data it tells me "Error: Incorrect padding"... It looks
> like, among other things, \n's are being turned into \\n's and not
> being converted back properly (this is from using short strings
> instead of full images;

Just another data point (and a rather useless one at that)--I've seen 
exactly the same thing even though I use Postgresql exclusively. I don't 
remember the exact circumstances when this occurred, other than it was 
when I was dealing with encoded binary values too.

...Edmund.

Re: [SQLObject] SQLite fails for binaries

[Joshua R. <jos...@mi...>]

On Sat, 06 Sep 2003 22:55:31 -0400
"Ian Bicking" <ia...@co...> wrote:

> You should add:
> 
>      def _set_content(self, value):
>          self._SO_set_content(base64.encodestring(value))
>      def _get_content(self):
>          return base64.decodestring(self._SO_get_content())
> 
> I'm not sure where the problem is, but this will make the whole thing 
> less error-prone.

Well having made that change and tested various things extensively I still have absolutely no clue what's going on, but now when I try to read the img data it tells me "Error: Incorrect padding"... It looks like, among other things, \n's are being turned into \\n's and not being converted back properly (this is from using short strings instead of full images; everything just seems to get garbled with big images).. And it still works properly under PostgreSQL. I have no idea if the problem is with my code, SQLObject's SQLite interface, PySQLite, or SQLite.  Although since it *does* work in other database systems its probably one of the latter three.  Hasn't anyone had this problem before?

Joshua Rothenberg

Re: [SQLObject] SQLite fails for binaries

[Ian B. <ia...@co...>]

On Saturday, September 6, 2003, at 09:35 PM, Joshua Rothenberg wrote:
> On Sat, 06 Sep 2003 21:53:27 -0400
> "Ian Bicking" <ia...@co...> wrote:
>> image = (wherever you are getting images from)
>> soinstance.image = image
>> assert soinstance.image == image
>
> All right, I added an assert to my wrapper function:
>
> def set_img(filename, data, refpage):
>    encodedData = base64.encodestring(data)
>    newImage = Image.new(name = filename, content = encodedData, page = 
> get_byname(refpage))
>    assert newImage.content == encodedData
>
> and the assertion fails..
> Here, I'll post the rest of the file:
>
> from SQLObject import *
> import base64
>
> __connection__ = SQLiteConnection('db.db')
>
> class record:
>    def __init__(self,name,content):
>       self.name=name
>       self.content=content
>
> class Image(SQLObject):
>    name = StringCol(alternateID=True)
>    content = StringCol()
>    page = ForeignKey('Page')
>

You should add:

     def _set_content(self, value):
         self._SO_set_content(base64.encodestring(value))
     def _get_content(self):
         return base64.decodestring(self._SO_get_content())

I'm not sure where the problem is, but this will make the whole thing 
less error-prone.

   Ian

Re: [SQLObject] SQLite fails for binaries

[Joshua R. <jos...@mi...>]

On Sat, 06 Sep 2003 21:53:27 -0400
"Ian Bicking" <ia...@co...> wrote:
> image = (wherever you are getting images from)
> soinstance.image = image
> assert soinstance.image == image

All right, I added an assert to my wrapper function:

def set_img(filename, data, refpage):
   encodedData = base64.encodestring(data)
   newImage = Image.new(name = filename, content = encodedData, page = get_byname(refpage))
   assert newImage.content == encodedData

and the assertion fails..
Here, I'll post the rest of the file:

from SQLObject import *
import base64

__connection__ = SQLiteConnection('db.db')

class record:
   def __init__(self,name,content):
      self.name=name
      self.content=content

class Image(SQLObject):
   name = StringCol(alternateID=True)
   content = StringCol()
   page = ForeignKey('Page')

class Page(SQLObject):
   title = StringCol(alternateID=True)
   content = StringCol()
   image = MultipleJoin('Image')

Image.createTable(ifNotExists=True)
Page.createTable(ifNotExists=True)
def get_byname(name):
   return Page.byTitle(name)

def get_search(name):
   return Page.select(LIKE(Page.q.title,('%' + name + '%')))

def set_upd(rec,oldtitle):
   Page.byTitle(oldtitle).set(title = rec.name, content = rec.content)

def set_new(rec):
   Page.new(title = rec.name, content = rec.content)

def set_del(name):
   Page.byTitle(name).destroySelf()

def del_img(name):
   Image.byName(name).destroySelf()

def get_img(name):
   return base64.decodestring(Image.byName(name).content)

def set_img(filename, data, refpage):
   encodedData = base64.encodestring(data)
   newImage = Image.new(name = filename, content = encodedData, page = get_byname(refpage))
   assert newImage.content == encodedData

def get_imgsearch(name):
   return Image.select(Image.q.name==name)

Re: [SQLObject] SQLite fails for binaries

[Ian B. <ia...@co...>]

On Saturday, September 6, 2003, at 07:55 PM, Joshua Rothenberg wrote:
> In an attempt to store binary files in a database, I tried using the
> previously suggested method of base64 encoding them. Whereas this 
> method
> works fine with PostgreSQL, it fails with SQLite. The string retrieved
> from the database is completely garbled from the (encoded) string 
> entered
> into the database. I also tried using hexadecimal encoding with the 
> same
> result. I have no idea what's causing this; is there anything I can do 
> to
> work around this problem? In this instance I wish to avoid using a full
> RDBMS, and I was really hoping to be able to store some images in the
> database (both those for the same reason: at least for now I want all 
> the
> data to reside in one file).  I'm using python 2.3 and had this result
> with both the 0.4 and CVS versions of SQLObject.

 From reading a little documentation, it seems that SQLite cannot have 
binary data because it uses null-terminated strings.  So, encoding is 
the only right way.  But then you tried base64 encoding.  I'm surprised 
that didn't work for you.  Can you give a snippet of the code you were 
using?  It should be quite reliable, so long as you are properly 
encoding and decoding the result, and base64-encoded values should be 
quite safe for insertion.  Is there a possibility the data is being 
corrupted before you put it into the database?  You might test that:

image = (wherever you are getting images from)
soinstance.image = image
assert soinstance.image == image

If that assert works, then the encoding is working.

> Ah, also, (I would respond to the proper message about this, but I 
> wasn't
> subscribed when it was posted), concerning Firebird, there is a pdf at
> http://www.ibphoenix.com/downloads/qsg.pdf that seems to cover all the
> basics of creating databases, etc. (it's linked to via a small image to
> the left of the front page; it's not linked to under documentation or
> anything reasonable like that....)

Thanks, I'll look at that too.  It'll all probably work well once I get 
it set up, but it's been a bit of a pain so far.  People don't give 
proper credit (or blame) for Open Source's general small innovations in 
creating easily administered software.  Anything proprietary (or in 
this case formally proprietary) has lots of difficulties in 
administration.

   Ian

[SQLObject] SQLite fails for binaries

[Joshua R. <Jos...@mi...>]

In an attempt to store binary files in a database, I tried using the
previously suggested method of base64 encoding them. Whereas this method
works fine with PostgreSQL, it fails with SQLite. The string retrieved
from the database is completely garbled from the (encoded) string entered
into the database. I also tried using hexadecimal encoding with the same
result. I have no idea what's causing this; is there anything I can do to
work around this problem? In this instance I wish to avoid using a full
RDBMS, and I was really hoping to be able to store some images in the
database (both those for the same reason: at least for now I want all the
data to reside in one file).  I'm using python 2.3 and had this result
with both the 0.4 and CVS versions of SQLObject.

Ah, also, (I would respond to the proper message about this, but I wasn't
subscribed when it was posted), concerning Firebird, there is a pdf at
http://www.ibphoenix.com/downloads/qsg.pdf that seems to cover all the
basics of creating databases, etc. (it's linked to via a small image to
the left of the front page; it's not linked to under documentation or
anything reasonable like that....)

Joshua Rothenberg

[SQLObject] Transaction fixes

[Ian B. <ia...@co...>]

Made a bunch of fixes to how transactions work in CVS.  Maybe they are 
now functional even, if not perfect.

I'm going to be keeping tarballs of CVS that are updated as I do stuff, 
so that interested parties don't have to wait for anon CVS to update 
(or be unsure whether they are working on an updated copy).  This will 
generally be in:
   http://colorstudy.com/ianb/SQLObject-cvs.tar.bz2

To flesh transaction support out a bit better, I'll soon be adding the 
ability to expire an instance -- when the instance is next accessed it 
will update itself from the database.  So on a rollback every object in 
the transaction will be expired.  I suppose on a commit every object 
outside of the transaction that is also present in the transaction 
should be expired.  But I'll have to think about that -- worries me to 
change objects other threads may be in the middle of working with.  
Anyway, you won't have to use _cacheValues=False with transactions 
then.  It will also expedite a .sync() method (or something along those 
lines).

   Ian

Re: [SQLObject] Alphanumeric Primary keys (maybe a FAQ)

[Frank B. <fb...@fo...>]

Hallo,
Sidnei da Silva hat gesagt: // Sidnei da Silva wrote:

> I think this question is quite commonly asked, 

Yes, it's a FAQ: 
 http://sqlobject.org/docs/SQLObject.html#sqlobject-requirements

> but does SQLObject support alphanumeric keys as the primary key
> (ID)?

As long as you intend to use the "alpha" in "alphanumeric": No(t yet)!

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] More transaction troubles

[Ian B. <ia...@co...>]

On Saturday, September 6, 2003, at 03:58 AM, Randall Randall wrote:
> Okay, so I got the current CVS, but transactions
> still seem to not work. :)
>
> >>> r = Person.new(firstName='my', lastName='lastname', 
> connection=trans)
> >>> r.firstName = 'Bob'
> >>> trans.commit()
> >>> r.firstName = 'Billy'
> >>> trans.rollback()
> >>> print r.firstName
> Billy

Hmmm... that's odd.  Maybe you should give debug=1 to your original 
connection and see what SQL is being sent.

> I thought that perhaps I needed to pull an object from
> the db in order to use transactions with it, so
>
> >>> del r
> >>> q = Person(1, trans)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
>   File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 
> 407, in __new__
>     val._init(id, connection, selectResults)
>   File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 
> 665, in _init
>     selectResults = (connection or 
> self._connection)._SO_selectOne(self, dbNames)
> AttributeError: 'Transaction' object has no attribute '_SO_selectOne'

Well, that's just a bug.   I'll look into it, I think I have a fix.  Of 
course it will go into CVS and you won't be able to check it for a day.

Which brings up the problem of anonymous CVS access on SF.  I'll have 
to write a script to make HEAD available in a more timely manner.

   Ian

Re: [SQLObject] More transaction troubles

[Randall R. <ra...@ra...>]

On Saturday, September 6, 2003, at 08:37 AM, Sidnei da Silva wrote:

> On Sat, Sep 06, 2003 at 04:58:49AM -0400, Randall Randall wrote:
> | >>> r.firstName = 'Billy'
> | >>> trans.rollback()
> | >>> print r.firstName
> | Billy
>
> A wild guess: rollback() isn't clearing the cache.

Just to clarify, I did have
_cacheValue = False
set in the Person class, which the 0.4 docs say is
supposed to be set when planning to use transactions.
I'm not sure if that's what you were talking about.

> It is also possible
> that you *think* you are using transactions, but in fact its not
> enabled on your database.

I wasn't sure if creating an object could use the
Transaction object instead of the connection object,
but that's why I tried to re-get it from the database,
and got
AttributeError: 'Transaction' object has no attribute '_SO_selectOne'
which seems like a separate problem in and of itself.

> Those are just guesses though, i havent
> actually looked at the code.

Thanks for the help, though!  SQLObject seems very
cool; now, if I can only figure out how to use it
properly... :)

-- 
Randall Randall <ra...@ra...>
"You assist an evil system most effectively by obeying its orders and 
decrees." -- Mahatma Gandhi
"When you advocate any government action, you must first believe that 
violence is the best answer to the question at hand." -- Allen Thornton

Re: [SQLObject] Firebird support

[David W. <da...@su...>]

Ian,

> I added the Firebird Database support that James Ralston wrote.  I also 
> have Firebird now installed on my computer to test it out, but I'm not 
> really sure how to set it upt, like how to create a database and set 
> permissions and such.  If anyone can give me some quick pointers (I 
> happen to be using the Debian packages, if that's useful), it would 
> allow me to do continued testing as SQLObject evolves.

isql -user SYSDBA -password masterkey create database dbfilename.gdb 
character set UNICODE_FSS

I think the debian package overrides the default password, so you
  may need to check its docs for that

All the docs for interbase (and firebird has not changed much in the way 
of interfaces) are available from ibphoenix.com at

http://ibphoenix.com/main.nfs?a=ibphoenix&s=1062851945:56928&page=ibp_download#DOCS

Dave

-- 
David Warnock, Sundayta Ltd. http://www.sundayta.com
iDocSys for Document Management. VisibleResults for Fundraising.
Development and Hosting of Web Applications and Sites.

[SQLObject] Alphanumeric Primary keys (maybe a FAQ)

[Sidnei da S. <si...@pl...>]

I think this question is quite commonly asked, but does SQLObject
support alphanumeric keys as the primary key (ID)?

[]'s
-- 
Sidnei da Silva <si...@pl...>
dreamcatching :: making your dreams come true
http://dreamcatcher.homeunix.org

Mommy, what happens to your files when you die?