sqlobject-discuss — All things SQLObject-related

[SQLObject] DBConnection for MS SQL Server / MSDE

[Sean M. H. <str...@ma...>]

I checked the archives for "SQL Server" and "SQLServer" but didn't find
anything--my apologies if I'm needlessly rehashing an old topic.
Anyway...has anyone already worked on providing DBConnection compatibility
with MS's SQL Server 2K or MSDE? If so, would you care to share? If not, are
other parties interested if I wind up going down the rabbit hole?

Thanks.

Sean

[SQLObject] MySQLConnection is deprecated

[Nigel K. <Ki...@di...>]

Hi,

I get the following warning on my MySQLConnection

/usr/local/lib/python2.3/site-packages/sqlobject/__init__.py:23: 
DeprecationWarning: MySQLConnection is deprecated; use 
connectionForURI("mysql://...") or "from sqlobject.mysql import 
builder; MySQLConnection = builder()"
   _warn('MySQLConnection is deprecated; use 
connectionForURI("mysql://...") or "from sqlobject.mysql import 
builder; MySQLConnection = builder()"')

In the manual it says to use
conn = MySQLConnection(user='test', db='testdb')
which is the method I use.

What is actually intended?

Nigel King

[SQLObject] Feature Request: Can Registry call a factory method if a class is not found?

[Scott S. <sc...@st...>]

Ian,

I have successfully been using SQLObject svn trunk for a few days now, 
without modifications.  I have implemented automatic class generation 
by reading information from the database about classes and their 
columns and joins.  I did this by extending MetaSQLObject with my own 
behavior, and a factory method called getClass(classname), which checks 
the registry, and then constructs a new class if the registry does not 
contain the proper class.

The problem I am running into now, is when you have joined classes, the 
joined classes have to be explicitly loaded.  In your users/roles 
example, my code would have to look something like this:
userClass = getClass('user')
roleClass = getClass('role') #if this is not called here, user.roles 
will not be defined, because the role class is not in the registry
user = userClass.get(1)
print list(user.roles[0])

It would great if the registry was allowed to have a factory method set 
to attempt automatic class creation if the class does not exist.  If I 
coded this up as a patch, would it be accepted?

Thanks,
Scott

Re: [SQLObject] SQLObject and python 2.2

[Andrew B. <and...@pu...>]

On Fri, Oct 29, 2004 at 12:34:48PM +0200, Josu Oyanguren wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> i think there is a little problem in SQLObject and python 2.2. I am
> trying a line like this:
> 
> matriculas = MultipleJoin('MatriculaDeCentro', joinColumn='IDCURSO',
> joinMethodName='matriculas')
> 
[...]
> AttributeError: 'dict' object has no attribute 'pop'
> - ------------------------------------------------------------
> 
> (pop method for dicts is new in python2.3, i think)
> 
> Not a big problem to me. I can workaround this.

Already fixed in SVN, I believe.

-Andrew.

[SQLObject] SQLObject and python 2.2

[Josu O. <jo...@ub...>]

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

Hi,

i think there is a little problem in SQLObject and python 2.2. I am
trying a line like this:

matriculas = MultipleJoin('MatriculaDeCentro', joinColumn='IDCURSO',
joinMethodName='matriculas')

and i get

- ------------------------------------------------------------
Traceback (most recent call last):

~  (...)

~  File "/disc2/home/josu/Aplicaciones/fundageneral/UsuarioDeCentro.py",
line 291, in CursoDeCentro
~    matriculas         = MultipleJoin('MatriculaDeCentro',
joinColumn='IDCURSO', joinMethodName='matriculas')
~  File "/usr/lib/python2.2/site-packages/sqlobject/joins.py", line 21,
in __init__
~    self._joinMethodName = self.kw.pop('joinMethodName')
AttributeError: 'dict' object has no attribute 'pop'
- ------------------------------------------------------------

(pop method for dicts is new in python2.3, i think)

Not a big problem to me. I can workaround this.

Anyway, this is a wonderful work.

- --



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

iD8DBQFBghzI5ju4HVxhuqQRAszcAJ4iYmXWkHCixuNteYU01K+3InswGwCgu3/J
qc5m4WEVcShAH3JaqqEp73E=
=IbGi
-----END PGP SIGNATURE-----

Re: [SQLObject] by<Columnname> method for ForeignKey column

[Charles B. <li...@st...>]

Ksenia,

I've never tried using a ForeignKey as an alternateID too.  There is
probably a more elegant way, but in this case I usually just use a select.
If you want to select a given question based on the component, you can do
something like:

qs = Question.select(Question.q.componentID==c.id)
if qs.count():
    q = qs[0]


HTH,
-Charles.
----- Original Message ----- 
From: "Ksenia Marasanova" <ks...@ks...>
To: "SQLObject discussion" <sql...@li...>
Sent: Thursday, October 28, 2004 6:47 PM
Subject: [SQLObject] by<Columnname> method for ForeignKey column


> Hi all,
>
> I have a table with unique ForeignKey, because it has one-to-one
> relationship with another table:
>
> class Question(SQLObject):
>      question = StringCol()
>      component = ForeignKey('Component', alternateID=True, cascade=True)
>
> But  Question.byComponent() doesn't work:
> AttributeError: type object 'Question' has no attribute 'byComponent'
>
> Shouldn't it be used that way? Sorry if I am missing something, it's
> kind of late and this is my first application with SQLObject.
>
> BTW, it's an amaizingly cool component that saves a lot of boring work
> :) Many thanks to Ian Bicking for creating it.
>
> Ksenia.
>
>
>
> -------------------------------------------------------
> This Newsletter Sponsored by: Macrovision
> For reliable Linux application installations, use the industry's leading
> setup authoring tool, InstallShield X. Learn more and evaluate
> today. http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

[SQLObject] by<Columnname> method for ForeignKey column

[Ksenia M. <ks...@ks...>]

Hi all,

I have a table with unique ForeignKey, because it has one-to-one 
relationship with another table:

class Question(SQLObject):
     question = StringCol()
     component = ForeignKey('Component', alternateID=True, cascade=True)

But  Question.byComponent() doesn't work:
AttributeError: type object 'Question' has no attribute 'byComponent'

Shouldn't it be used that way? Sorry if I am missing something, it's 
kind of late and this is my first application with SQLObject.

BTW, it's an amaizingly cool component that saves a lot of boring work 
:) Many thanks to Ian Bicking for creating it.

Ksenia.

Re: [SQLObject] SQLObject+Quixote+SCGI

[Ksenia M. <ks...@ks...>]

>
>    Well, now I do as follows. Firest, transactions. I initialize
> transactions in my DB.py, where I declare all my tables:
>
> from Cfg import dbName, dbUser, dbPassword, dbHost
> dbConn = PostgresConnection(db=dbName, user=dbUser, passwd=dbPassword, 
> host=dbHost)
> dbConn.debug = True
>
> transaction = dbConn.transaction()
> transaction._makeObsolete() # prepare for .begin()
>
> def transaction_begin():
>    transaction.begin()
>
> def transaction_commit():
>    transaction.commit()
>
> def transaction_rollback():
>    transaction.rollback()
>
>
> # the parent class for all my tables
> class Table(SQLObject):
>    _connection = transaction
>
>
>    In the main script:
>
> class MyPublisher(Publisher):
>
>     def process_request(self, request, env):
>         from DB import transaction_begin, transaction_commit, 
> transaction_rollback
>         transaction_begin()
>         try:
>            output = Publisher.process_request(self, request, env)
>         except:
>            transaction_rollback()
>            raise
>         else:
>            transaction_commit()
>         return output
>
>
>    Second, forking. I have to delay importing DB until after forking.
> Actually, I import it now only when it is required. In main script 
> right
> in process_request(), in other modules - in appropriate methods. This
> late import delays creating the connection, so the real connection to
> the database is being created late enough - after SCGI has forked.
>

Thank you for sharing - it was very helpful!

Ksenia.

Re: [SQLObject] SQLObject+Quixote+SCGI

[Oleg B. <ph...@ma...>]

On Wed, Oct 27, 2004 at 11:15:29AM +0200, Ksenia Marasanova wrote:
> Op 24-okt-04 om 14:04 heeft Oleg Broytmann het volgende geschreven:
> >   People, how do you handle forks and transactions?
> 
> I am on the same path (SQLObject + Quixote + SCGI), but earlier - 
> worring about more primitive things yet :) But I share your concern. 
> There is a mention of preferred connection approach in Quixote on this 
> page: http://wiki.sqlobject.org/connections.html, but it's all I can 

   I saw it already, of course. Actually, I have searched SQLObject and
Quixote mailing lists using Google and Gmane.

> find. Maybe it's related to the forking problem?
> More comments are greatly appreciated...

   Well, now I do as follows. Firest, transactions. I initialize
transactions in my DB.py, where I declare all my tables:

from Cfg import dbName, dbUser, dbPassword, dbHost
dbConn = PostgresConnection(db=dbName, user=dbUser, passwd=dbPassword, host=dbHost)
dbConn.debug = True

transaction = dbConn.transaction()
transaction._makeObsolete() # prepare for .begin()

def transaction_begin():
   transaction.begin()

def transaction_commit():
   transaction.commit()

def transaction_rollback():
   transaction.rollback()


# the parent class for all my tables
class Table(SQLObject):
   _connection = transaction


   In the main script:

class MyPublisher(Publisher):

    def process_request(self, request, env):
        from DB import transaction_begin, transaction_commit, transaction_rollback
        transaction_begin()
        try:
           output = Publisher.process_request(self, request, env)
        except:
           transaction_rollback()
           raise
        else:
           transaction_commit()
        return output


   Second, forking. I have to delay importing DB until after forking.
Actually, I import it now only when it is required. In main script right
in process_request(), in other modules - in appropriate methods. This
late import delays creating the connection, so the real connection to
the database is being created late enough - after SCGI has forked.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject+Quixote+SCGI

[Ksenia M. <ks...@ks...>]

Op 24-okt-04 om 14:04 heeft Oleg Broytmann het volgende geschreven:
>    People, how do you handle forks and transactions?
>
>    I use Quixote+SCGI(+Apache); my program is a long-living (Quixote)
> forking (SCGI) process. The thing that is worrying me is that I import 
> a
> module that defines my tables almost before anything else. The module
> opens a connection to a Postgres database, and then SCGI forks the
> program.
>    Should I worry? Shoud I close and reopen the connection? What about
> transactions?
>

I am on the same path (SQLObject + Quixote + SCGI), but earlier - 
worring about more primitive things yet :) But I share your concern. 
There is a mention of preferred connection approach in Quixote on this 
page: http://wiki.sqlobject.org/connections.html, but it's all I can 
find. Maybe it's related to the forking problem?
More comments are greatly appreciated...

Ksenia.

Re: [SQLObject] form generation/validation

[Carlos R. <car...@gm...>]

On Mon, 25 Oct 2004 17:24:37 +0100, Jamie Hillman
<ma...@ja...> wrote:
> It would be nice if SQLObject did preserve ordering as it would 
> make form-generation hacks like mine a bit easier :-)

I've sent a copy of this reply to the list; I think it's relevant, and
I hope you don't mind.

Not only form generation, but any declarative style add-on would be
easier to integrate. Examples are reports and views. Also, tables
created by SQLObject would have its columns correctly ordered in the
database, which is a small plus. Its somewhat strange to check the
database using another tool and see the columns in arbitrary order.
Not a big deal, but strange nonetheless.

> Yeah I see what you're saying here but when implementing something 
> simple, as I am, it seems wasted effort to generate two schemas (one
> for forms, one for the database).  Though you could still use the one
> schema and have different objects "decorating" the information for 
> different purposes.

The problem is that applications tend to stay simple for a very short
period of time :-) My own idea is similar to a 'decorator'. I'm now
studying aspects, and aspect oriented programming, in my plentiful
spare time (of course, this is a joke -- the spare time, that is). 
For what I have read, AOP tools (such as JAspect) already solve some
of the complex theorethical issues, including the development of
advanced graph representations for what they call 'cross-cutting
concerns' -- aspects that affect the software in orthogonal ways, and
that support really complex combinations of code. So I don't have
really a way to foresee when will I be able to push again on real
development. My current model is confusing and I don't intend to push
it beyond it's limits .

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] form generation/validation

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

Jamie Hillman wrote:
> Hi,
> 
> I was just wondering what kind of state integration with FormEncode
> was in?  I started writing code to generate forms from (and validate
> forms against) SQLObject schemas myself, then I realised it was a
> future goal for SQLObject.  From reading the FormEncode docs it seems
> that it will read form specifications from schemas but it doesn't
> mention SQLObject schemas.  Is there any useable code out there?

Eh... at the moment FormEncode is kind of broken, and there were just 
too many issues to try to deal with all of them at once.  It was just 
too fragile, so I'm trying to simplify it.

Ultimately, the problem is hard -- I really want to be able to edit a 
set of objects at once, not just a single object, so that UI isn't 
unnecessarily tied to the way the backend objects are factored. 
FormEncode has all the basic features to do this, and I'd started 
playing around with ways of defining graphs of objects, so you could 
deal with complex subobjects.  E.g., one attribute might be immutable, 
so if you change it you'd actually remove the attribute (maybe deleting 
it from the database) and add a new one.  Or, another attribute is a 
list of objects, each of which has its own behavior.  Or another 
attribute contains an object that can be edited in place.  Even fairly 
simple systems of objects can be fairly complex from that perspective. 
But maybe trying to define the controller declaratively in this way was 
too ambitious.

> The were two problems in generating/validating forms with my
> implementation that I might as well mention whilst i'm here, to see
> what you think.  The first problem was ordering - i'd like to keep
> the generated form fields in the same order as they appear in the
> schema.  This _columns dictionary didn't preserve this order and from
> looking at the code it would seem that this is unavoidable?  I ended
> up creating a separate list of COL objects which preserved the order
> and using that to generate forms.

In FormEncode the order of fields is preserved.  In that case everytime 
a class is instantiated we increment a global counter, and if you sort 
based on that counter you get the order of the objects.  Since in 
FormEncode you can also use classes in place of objects, there's a 
metaclass that adds the counter to classes as well (though that leads to 
a certain amount of confusion).  Anyway, it's implemented in declarative.py

> The second "problem" was generating a readable name for fields in
> forms (I generate a table with prompts next to each field), which I
> just did by adding a property to the columns - prettyName.
> 
> So far i'm generating forms well enough, and i'm just about to start
> validation code.

I've separated out the validation code from FormEncode, just this Friday 
or so.  It's in svn://colorstudy.com/trunk/Validator -- it's the part of 
FormEncode that has been the most stable, and where I don't expect any 
changes (well, I actually started making some API changes when I moved 
it out, but anyway...).  It still uses PyProtocols, but I might take 
that out; it's just been too confusing to deal with all the different 
mechanisms, and PyProtocols is a more subtle mechanism than most.

Like Carlos said, it gets rather confusing when you consider all the 
paths data can take.  I think it's better to start out very explicit, 
and then build up abstractions, so I'm trying to pull back to something 
more explicit.

Validator still uses DataTest (svn://colorstudy.com/trunk/DataTest), but 
I plan to move it to py.test (http://codespeak.net/py/current/doc/test.html)

> So I guess the point of my long rambling email is to see if any of
> this has been done already and if I can get hold of that code, and if
> not if I can help out by making my code fit your goals.
> 
> Thanks for your work on SQLObject,

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] form generation/validation

[Carlos R. <car...@gm...>]

On Mon, 25 Oct 2004 10:51:21 +0100, Jamie Hillman
<ma...@ja...> wrote:
000000000000000000000000000000000000000000000000000000000000
> The first problem was ordering - i'd like to keep the generated form 
> fields in the same order as they appear in the schema.  This _columns
> dictionary didn't preserve this order and from looking at the code it 
> would seem that this is unavoidable?  I ended up creating a separate 
> list of COL objects which preserved the order and using that to generate 
> forms.

Hi Jamie,

I've had a conversation a few days ago with Ian regarding FormEncode
and generic 'declarative' issues. I've written a order-preserving
metaclass to solve another problem, but I think that the same approach
could be used in SQLObject. Python doesn't give low-level support for
ordering; dicts don't store ordering information, and classes uses
normal dicts to store members as they are created. To solve this
problem, you need to order the columns yourself. The basic idea is
that the column attributes can be numbered as they are created, using
a simple counter (derived from itertools.count(), in my case). This
number is an internal attribute of the column and can be used to sort
them.

** Another approach was suggested a c.l.py a few days ago, that is
generic and doesn't required the attributes to store any information;
it involves checking the stack frame and the co_names member of the
function code block (which lists the locals in the order that they
were declared), but that's not needed for SQLObject as all interesting
objects are already classes that can implementing the ordering
behavior themselves.

> The second "problem" was generating a readable name for fields in forms (I generate a table with prompts next to each field), which I just did by adding a property to the columns - prettyName.
> 
> So far i'm generating forms well enough, and i'm just about to start validation code.

My personal conclusion after talking to Ian on this is that it's
difficult to mix several 'aspects' of the fields into a single
representation. In other words, as you add functionality to SQLObject,
the structure starts to become confusing and less manageable. For
example: the ordering isn't always the same for all operations (table
definition, form definition, and validation); the same table can be
viewed in several diffferent ways (more than one form); validation
rules may change upon context.

I don't have a solution for this problem (yet :-)), but I think that
it's better to keep each part of the problem into their own object,
and make all objects aware of each other and able to play together. In
this scenario, SQLObject takes care of the data definition and
persistence; FormEncode (or another similar solution) takes care of
form definition; a validation object stores the validation rules, and
can be passed to the form definition. It's not the end of it --
reports, advanced lookup lists, and other types of objects can be also
implemented.

Of course, that's *my own understanding of the problem*, and by no
means it's the only possible solution. I'm working on it, but my code
is still pretty much experimental, and still subject to huge changes,
but I would love to discuss it.
 


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] form generation/validation

[Jamie H. <ma...@ja...>]

Hi,

I was just wondering what kind of state integration with FormEncode was in?  I started writing code to generate forms from (and validate forms against) SQLObject schemas myself, then I realised it was a future goal for SQLObject.  From reading the FormEncode docs it seems that it will read form specifications from schemas but it doesn't mention SQLObject schemas.  Is there any useable code out there?

The were two problems in generating/validating forms with my implementation that I might as well mention whilst i'm here, to see what you think.  The first problem was ordering - i'd like to keep the generated form fields in the same order as they appear in the schema.  This _columns dictionary didn't preserve this order and from looking at the code it would seem that this is unavoidable?  I ended up creating a separate list of COL objects which preserved the order and using that to generate forms.

The second "problem" was generating a readable name for fields in forms (I generate a table with prompts next to each field), which I just did by adding a property to the columns - prettyName.

So far i'm generating forms well enough, and i'm just about to start validation code.

So I guess the point of my long rambling email is to see if any of this has been done already and if I can get hold of that code, and if not if I can help out by making my code fit your goals.

Thanks for your work on SQLObject,

Jamie Hillman

[SQLObject] SQLObject+Quixote+SCGI

[Oleg B. <ph...@ph...>]

Hello!

   As far as I understand more and more people use SQLObject+Quixote
these days. There is a question I'd like to ask.

   People, how do you handle forks and transactions?

   I use Quixote+SCGI(+Apache); my program is a long-living (Quixote)
forking (SCGI) process. The thing that is worrying me is that I import a
module that defines my tables almost before anything else. The module
opens a connection to a Postgres database, and then SCGI forks the
program.
   Should I worry? Shoud I close and reopen the connection? What about
transactions?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] problems with SQLObject autonaming scheme

[Max I. <ma...@uc...>]

Carlos Ribeiro wrote:

> It seems that you've had hit the same problem I had last week. I have
> posted a few messages here; in the last one there is a suggestion for
> a ammendment to the documentation, in the tutorial part. I don't know
> if Ian has read it though.

The funny things is that I did search mailing list before posting my 
question and I even did read your mail and the follow-ups - I just 
didn't realize it was the answer to my question as well. ;-)


> The solution is simple -- use the joinColumn argument in your
> MultipleJoin entry, as follows:
> 
>  class OrderGateway(SQLObject):
>       name = StringCol()
>       prints = MultipleJoin('PrintGateway', joinColumn='order')

I had to change last line to
         prints = MultipleJoin('PrintGateway', joinColumn='order_id')

 >
 >  class PrintGateway(SQLObject):
 >       size = StringCol()
 >       order = ForeignKey('OrderGateway')
 >

Thanks a lot!

Re: [SQLObject] problems with SQLObject autonaming scheme

[Carlos R. <car...@gm...>]

On Thu, 21 Oct 2004 17:23:24 +0300, Max Ischenko <ma...@uc...> wrote:
> 
> Hi,
> 
> I need to setup simple one-to-many relation but has problems due (I
> guess) SQLobject's magic autonaming scheme.
> 
> Here is my code:
> 
> class OrderGateway(SQLObject):
>      name = StringCol()
>      prints = MultipleJoin('PrintGateway')
> 
> class PrintGateway(SQLObject):
>      size = StringCol()
>      order = ForeignKey('OrderGateway')
> 
> dborder = OrderGateway(name='me')
> print dborder.prints
> 
> The last statement gives this error:
> psycopg.ProgrammingError: ERROR:  column "order_gateway_id" does not exist

It seems that you've had hit the same problem I had last week. I have
posted a few messages here; in the last one there is a suggestion for
a ammendment to the documentation, in the tutorial part. I don't know
if Ian has read it though.
 
> I can fix it by renaming column order to order_gateway, but I don't want
> to. I also can't rename OrderGateway class to Order class because than I
> would get a clash with SQL reserved keyword and anyway, I don't want to
> neither. ;-)

The solution is simple -- use the joinColumn argument in your
MultipleJoin entry, as follows:

 class OrderGateway(SQLObject):
      name = StringCol()
      prints = MultipleJoin('PrintGateway', joinColumn='order')
 
 class PrintGateway(SQLObject):
      size = StringCol()
      order = ForeignKey('OrderGateway')


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] problems with SQLObject autonaming scheme

[Max I. <ma...@uc...>]

Hi,

I need to setup simple one-to-many relation but has problems due (I 
guess) SQLobject's magic autonaming scheme.

Here is my code:

class OrderGateway(SQLObject):
     name = StringCol()
     prints = MultipleJoin('PrintGateway')

class PrintGateway(SQLObject):
     size = StringCol()
     order = ForeignKey('OrderGateway')

dborder = OrderGateway(name='me')
print dborder.prints

The last statement gives this error:
psycopg.ProgrammingError: ERROR:  column "order_gateway_id" does not exist

I can fix it by renaming column order to order_gateway, but I don't want 
to. I also can't rename OrderGateway class to Order class because than I 
would get a clash with SQL reserved keyword and anyway, I don't want to 
neither. ;-)

I tried to change order's definition to:
     order = ForeignKey('OrderGateway', name='order_gateway')
but this gives another error:

Traceback (most recent call last):
   File "D:\Python23\Lib\site-packages\sqlobject\main.py", line 70, in 
__new__
     value.name = attr
   File "D:\Python23\lib\site-packages\sqlobject\col.py", line 277, in 
_set_name
     assert self._name is None, "You cannot change a name after it has 
already been set (from %s to %s)" % (self.
_name, value)
AssertionError: You cannot change a name after it has already been set 
(from order_gateway to order)


So, any ideas how can I make SQLObject to honor and use the naming 
scheme I'm trying to impose on it?


Thanks.
I'm using SQLObject from SVN repository.

Re: [SQLObject] Obj.destroySelf() and Obj.sync()

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

Andrew Bennetts wrote:
> Hi,
> 
> Is it intentional that doing:
> 
>     Obj.destroySelf()
>     Obj.sync()
> 
> will raise an error?  
> 
> More generally, what operations on an SQLObject are valid after destroySelf
> has been called on it?  The current comment of "Kills this object.  Kills it
> dead!" doesn't tell me very much :)

Nothing should be valid after an object has been destroyed.  The object 
is just a corpse at that point; unfortunately there's no way to actually 
remove it from the system (except garbage collection, which we don't 
control).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[SQLObject] Obj.destroySelf() and Obj.sync()

[Andrew B. <and...@pu...>]

Hi,

Is it intentional that doing:

    Obj.destroySelf()
    Obj.sync()

will raise an error?  

More generally, what operations on an SQLObject are valid after destroySelf
has been called on it?  The current comment of "Kills this object.  Kills it
dead!" doesn't tell me very much :)

-Andrew.

[SQLObject] Registry and database auto-generation...

[Michel T. <mic...@ya...>]

Hi guys,

I found another problem i think it's a bug. It casual to have a table
called article on several databases, different ones. I use webware to
make my programs interfaces, this naming convention cause me problems
on time it does cache of the data, I didn't know well this stuff, I
only knew that I must use the class variable _registry.

This works well for already made databases, but I can't generate a
database using the Database.createTable(), it generates me errors. I
downloaded the SQLObject from svn just this time, I will try and see if
the problem is still here then I send the errors message (if it
persist).

I have a problem with the name of an attribute, can I use _attribute as
column name without use forceDB? I got an error message saing I can't,
but the name is only alphanumeric and underscore... I solve using
attribute_...

Sorry my poor english, thanks for all help!

=====
--
Michel Thadeu Sabchuk
Curitiba/PR


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

[SQLObject] Re: Strange bug with SQLObject 0.6

[Carlos R. <car...@gm...>]

I've found my 'bug', and it hasn't nothing to do with naming
conventions. It was a mistake of mine: my one-to-many relationship
used a different column name from the default one, and I was not aware
that in this case I had to supply a joinedColumn parameter (in fact,
another user pointed it out to me, but I misunderstood his point, and
assumed that I just had to upgrade my SQLObject installation).

Regarding this problem, I have a suggestion: add a remark on the
"One-to-Many Relationships" section of the documentation. The relevant
information does exist but it's buried down in the MultipleJoin
reference; so when I replayed the example provided in the tutorial
section it worked, but I was not aware of the option, until I read the
reference. For example, something like this:

http://www.sqlobject.org/docs/SQLObject.html:
"""
We get the backreference with addresses = MultipleJoin('Address').
When we access a person's addresses attribute, we will get back a list
of all the Address objects associated with that person. An example:

p = Person(firstName='John', lastName='Doe')
print p.addresses
#>> []
a1 = Address(street='123', city='Smallsville',
                 state='IL', zip='50484', person=p)
print [a.street for a in p.addresses]
#>> ['123']

In this case, the relationship between the 'Person' entity and the
'Address.person' ForeignKey() column is detected and created with no
need for any extra information -- the name is mapped automatically.
However, if the name of the ForeignKey() column is different from the
entity name which it relates with, a joinedColumn argument will be
required. For example:

<...> 
"""

I found my mistake only after realizing that the join method had no
other way to find the joined-to column :-) But it's easy to overlook
it, because SQLObject abstracts very well from these 'implementation
details'. That's why I believe a comment early in the documentation
(or in a FAQ section) could be useful.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Re: Strange bug with SQLObject 0.6

[Carlos R. <car...@gm...>]

Hello all,

I just update my sqlobject installation, but I'm still having problems
with MultipleJoins. This time the problem seems to be a little easier
to diagnose, given the result of my test session:

>>> execfile('test_sqlobj.py')
>>> new_db()
>>> u = dbUser.get(1)
>>> u
<dbUser 1 user_address1='' user_password='' user_address2=''
user_city='' user_name='Carlos Ribeiro' user_nickname='cribeiro'
user_comments=''>
>>> u.workitems
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "<string>", line 1, in <lambda>
  File "C:\Python23\Lib\site-packages\sqlobject\joins.py", line 127,
in performJoin
    inst.id)
  File "C:\Python23\Lib\site-packages\sqlobject\dbconnection.py", line
408, in _SO_selectJoin
    return self.queryAll("SELECT %s FROM %s WHERE %s = %s" %
  File "C:\Python23\Lib\site-packages\sqlobject\dbconnection.py", line
217, in queryAll
    return self._runWithConnection(self._queryAll, s)
  File "C:\Python23\Lib\site-packages\sqlobject\dbconnection.py", line
125, in _runWithConnection
    val = meth(conn, *args)
  File "C:\Python23\Lib\site-packages\sqlobject\dbconnection.py", line
210, in _queryAll
    self._executeRetry(conn, c, s)
  File "C:\Python23\Lib\site-packages\sqlobject\dbconnection.py", line
196, in _executeRetry
    return cursor.execute(query)
  File "C:\Python23\Lib\site-packages\sqlite\main.py", line 244, in execute
    self.rs = self.con.db.execute(SQL)
DatabaseError: no such column: db_user_id


It seems that the sqlobject code that 'mangles' the column names is
trying to convert the 'uppercase-ID' convention that is used for
automatic primary keys to the 'underscore' convention. I'm not yet
familiar with sqlobject internals, though -- I'll attempt to fix it
myself, but no promises :-)

(btw, it seems that the problem was triggered by my own naming
convention. I'll just rename all entities and see what happens)

The script that defines the database is as follows:

---------------
from sqlobject import connectionForURI, SQLObject, StringCol, IntCol, \
                      FloatCol, ForeignKey, MultipleJoin

db = connectionForURI('sqlite:/work/test.db')

class dbWorkItem(SQLObject):
    _connection = db
    wi_name        = StringCol(length = 60, notNone = True)
    wi_description = StringCol(length = 200, notNone = True, default = '')
    wi_form_class  = StringCol(length = 40, notNone = True)
    wi_form_id     = IntCol(default=0)
    owner          = ForeignKey('dbUser')
    workflow       = ForeignKey('dbWorkFlow')

class dbUser(SQLObject):
    _connection = db
    user_nickname  = StringCol(length = 15, notNone = True, alternateID = True)
    user_password  = StringCol(length = 15, notNone = True, default = '')
    user_name      = StringCol(length = 40, notNone = True, default = '')
    user_address1  = StringCol(length = 40, notNone = False, default = '')
    user_address2  = StringCol(length = 40, notNone = False, default = '')
    user_city      = StringCol(length = 40, notNone = False, default = '')
    user_comments  = StringCol(length = 400, notNone = False, default = '')
    workitems      = MultipleJoin('dbWorkItem')

def new_db():
    dbUser.createTable()
    dbWorkItem.createTable()
    dbUser(user_nickname="cribeiro", user_name="Carlos Ribeiro")
    dbWorkItem(wi_name='task1', wi_description='Task 1',
wi_form_class='', workflow=None, owner=1)
    dbWorkItem(wi_name='task2', wi_description='Task 2',
wi_form_class='', workflow=None, owner=1)


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Cannot checkout from svn

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

Stupid bdb.  I don't know why it keeps becoming corrupted.  I think I'm 
going to have to disable viewcvs.py.  Anyway, for the moment it should 
be fixed.

Scott Sanders wrote:
> Executing:
> svn co svn://colorstudy.com/trunk/SQLObject
> 
> Gives the following error.
> svn: Berkeley DB error while opening 'nodes' table for filesystem 
> /var/lib/subversion/repository/db:
> Cannot allocate memory
> 
> Seems to be a remote error, as I have tried from a Windows, Linux, and 
> Mac OS X client, and all give the same error.
> 
> What needs to be done?

Re: [SQLObject] Identity crisis.

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

Alan Kennedy wrote:
> [Alan Kennedy]
>  >> I'm trying to pickle SQLObjects, so that I can store them in
>  >> structured documents. As far as I can see, pickles only need to
>  >> contain the name of the SQLObject class, and the id which uniquely
>  >> identifies the instance.
> 
> [Brian Ray]
>  > I thought SQLObject does not support pickleing because it uses pickel
>  > for persistance:
>  >
>  > http://sourceforge.net/mailarchive/message.php?msg_id=7578480
> 
> Thanks for pointing out that reference Brian, I hadn't seen it before.
> 
> Looking at Ian's message at that url, it looks like he's talking about 
> support for pickling the entire SQLObject, which I would imagine would 
> have complex consequences when it comes to connections, etc, because 
> object identity seems to be related to the connection that the object 
> came from.

I was just thinking about a reference (i.e., no column data).  The 
reference might or might not include the connection; both instances have 
valid use cases.  E.g., the connection may often be configurable, and if 
you change the configuration and load the pickle you may want lot load 
it from the newly configured connection, not the old connection.  OTOH, 
if you are using multiple databases, you may want the connection 
included in the reference.

__setstate__ would require refactoring SQLObject a bit, so that it could 
set up all the special variables that SQLObject creates in __init__. 
That would be doable.  Another option would be to implement __new__, and 
potentially include some magic keyword argument that would cause a 
.get() to be called.  Of course, __init__ gets *re*-called if __new__ 
returns an instance of the class.  Frankly __new__ is a stupid, stupid 
method.

Which makes me think __setstate__ may be the better way to go.  Oh, 
wait, no... that's no good either.  Because sometimes you'll be 
returning an existing instance when unpickling, if that row has already 
been loaded up.  Blah.  And what if you want to load the objects into a 
transaction?  Then you'd want to say, "unpickle to this connection". 
Again, rather annoying, since there's no way to pass information from 
the pickler into the class, except through a global.

At that point, a pickle subclass starts to seem better, where this 
configuration information could be stored in the pickle subclass.

Blah.  Well, there's my indecisive opinion.

-- 
Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org