sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Transaction Implmentation

[Luke O. <lu...@me...>]

> I don't fully grok the code yet, but from what I see -- it looks
> like
> most of the changes inside methods in SQLObject are probably the
> right
> way to do things even without these transactions.

That's what it seemed like. Cool.

> Now, I'm still not sure why there's a distinction between
> MemoryConnection and Transaction -- they seem like they could be
> the same class.

That was just for my sake as it came together, they could easily be
combined.

> With connections:
>
> trans = MemoryTransaction(persistentConnection)
> a = Class.new(connection=trans, ...)
> # New copyToConnection method, works between any connections...
> b = inst.copyToConnection(trans)

Hmm. yep, that's really all addToTransaction is, and _persist is just
copyBackToClassConnection, which could be the default arg behavior
for copyToConnection.

The one thing I've found handy with the Transaction idea is that it's
an obvious grouping mechanism for a collection of temp objects.
Anyways, the interface you suggest above is very compatible with how
I've built things, so long as we keep
MemoryTransaction.commit()/rollback().

Also, I think it would be good to simplify things somewhat inside
MemoryTransaction to only have a single persistentConnection, as
opposed to tracking per-class connections (which are likely all the
same). Especially since I had to ignore the per-class thing for
joins, where I don't know what class it's coming from. :) Only thing,
I'd probably make it so it'll transparently pick up the connection
from the first object added to it, as opposed to a necessary explicit
part of __init__. (When I'm writing user-side SQLObject code, I never
have direct access to the connection object being used, unless we
want to promote explicit inst._connection access.)


> Perhaps a different name than "connection" will make this feel
> conceptually more clear -- *Connection is something of a misnomer,
> that's only a small part of the functionality, and new things like
> DBMConnection and MemoryConnection aren't connections.

Yes, I like the name MemoryTransaction actually. Although it's not
particularily clearer what it does...

> Couldn't the connection's cache just be a sort of no-op, to achieve
> the same thing?  That is, MemoryConnection's cache attribute just
> returns None on .get(), and ignores .put().

The problem here (why I needed to turn off caching explicitly) was
that copyToConnection first created a new instance using the
old/persistant connection, which we didn't want cached. Now, if we
ensure that MemoryTransaction already has a persistantConnection
(either by setting it explicitly in copyToConnection, or in its
__init__), then this requirement can go away, and behave as you
suggest. Sounds good. I don't care whether MemoryTransaction's cache
picks it up or not, as MemoryTransaction can't currently be used for
a primary connection type anyways.

A side note: I'm having MemoryTransaction use negative object IDS for
newly created temp objects to distinguish and avoid clashes. Anyone
forsee a problem with this? I can't recall seeing a database that
used negative SERIAL/AutoIncrement fields, but I suppose it could
happen...

Let me merge these ideas together, I'll throw up a new email in the
morning. Summary: simplify to single MemoryTransaction class with
single persistantConnection, and single copyToConnection method in
SQLObject. Alrighty.

- Luke

Re: [SQLObject] Transaction Implmentation

[deelan <de...@in...>]

Luke Opperman wrote:

 > Hello all -
 >
(...)

 > Well, after finding time, and getting today's CVS, I'm very pleased to
 > announce a test implementation of Python-side Transactions for
 > SQLObject.


somewhat related: new transaction support is working for mysql
too? i've been told that recent mysql versions support
transactions natively, older ones do not. does sqlobject ask
rdbms system for transaction support and act conseguently or mysql trans
support is yet to be written?

BTW, great work. :)

Re: [SQLObject] Transaction Implmentation

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

On Mon, 2003-05-12 at 16:26, Luke Opperman wrote:
> (Tried sending this, I guess 70K attachments are just on the edge of
> kosher, so get the file here: http://www.amoebagod.com/SQLObject.zip
> )

Yeah, and I've forgotten the admin password, so I couldn't pass it
through :-(

I don't fully grok the code yet, but from what I see -- it looks like
most of the changes inside methods in SQLObject are probably the right
way to do things even without these transactions.  

Now, I'm still not sure why there's a distinction between
MemoryConnection and Transaction -- they seem like they could be the
same class.

> Well, after finding time, and getting today's CVS, I'm very pleased to
> announce a test implementation of Python-side Transactions for
> SQLObject.
> 
> Interface:
> 
> New exported class 'Transaction' (yes, I know there's already a
> Transaction class in DBConnection, but I couldn't come up with an
> alternate name, and they won't clash for now.)
> 
> Public Transaction methods:
>   t = Transaction()
>   t.commit()
>   t.rollback()
> 
> New methods in SQLObject:
> 
>   a = Class.newForTransaction(trans, ...) same as classmethod "new()"
>   b = inst.addToTransaction(trans) copies inst to the transaction
> (inst remains un-transactioned in this case, although you could do
> inst = inst.addToTransaction(trans) )

With connections:

trans = MemoryTransaction(persistentConnection)
a = Class.new(connection=trans, ...)
# New copyToConnection method, works between any connections...
b = inst.copyToConnection(trans)

The MemoryTransaction (or whatever it is called -- I feel like "temp"
should be the name somewhere)... it also happens to keep track of things
so it can copy objects back on commit.  It seems like a nice orthogonal
feature, because I can imagine copying between connections besides just
transactions.

Perhaps a different name than "connection" will make this feel
conceptually more clear -- *Connection is something of a misnomer, as
that's only a small part of the functionality, and new things like
DBMConnection and MemoryConnection aren't connections.

>   __new__() now takes an additional argument 'useCache' to forcefully
> avoid caching of a specific instance. This is for addToTransaction,
> where we create a clean instance and then switch connections (but
> don't want any record in the class/original connection cache)

Couldn't the connection's cache just be a sort of no-op, to achieve the
same thing?  That is, MemoryConnection's cache attribute just returns
None on .get(), and ignores .put().  The effect is no caching.

>   new() now sets inst._connection = kw['connection'] if a connection
> is passed in. I'm not sure if this will break other expected
> behavior, but it seems reasonable to me.

Yes, that should be in there anyway.

>   RelatedJoin: performJoin, add, remove:  these all now use 'inst'
> argument instead of self.callingClass to get a connection from.
> Again, not sure if this will break expected behavior, but seems
> reasonable to me. (I need this because, along with the previous
> change, I am expecting true per-object connections when I ask for it.
> :)

Yes, sounds right too.

  Ian

Re: [SQLObject] thoughts on structure and components

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

On Mon, 2003-05-12 at 10:39, Bud P.Bruegger wrote:
> > Now, if I'm reading it right, this would be the most significant
> > difference with SQLObject -- a mapping object is a separate from the
> > class.  But why?  
> 
> Ian, I made some progress and I can more clearly answer to the
> question above:
> 
> In this approach, relationships are instances managed by Mapping, not
> part of the "class" (of the storable application object).  This way,
> to keep object references from the relationship object to the
> contained (from, to..) "table objects" (that I call ObjMap).  I can
> also keep back-references from ObjMap to all the relations that
> reference it.  
> 
> This way, I avoid (at least it seems at the moment) all problems of
> circular dependencies, referencing to objects only by name, etc.  

I'm still not really clear what you're thinking.  Can you show how you
might define a class, using a mapping?

  Ian

[SQLObject] Transaction Implmentation

[Luke O. <lu...@me...>]

Hello all -

(Tried sending this, I guess 70K attachments are just on the edge of
kosher, so get the file here: http://www.amoebagod.com/SQLObject.zip
)

Well, after finding time, and getting today's CVS, I'm very pleased to
announce a test implementation of Python-side Transactions for
SQLObject.

Interface:

New exported class 'Transaction' (yes, I know there's already a
Transaction class in DBConnection, but I couldn't come up with an
alternate name, and they won't clash for now.)

Public Transaction methods:
  t = Transaction()
  t.commit()
  t.rollback()

New methods in SQLObject:

  a = Class.newForTransaction(trans, ...) same as classmethod "new()"
  b = inst.addToTransaction(trans) copies inst to the transaction
(inst remains un-transactioned in this case, although you could do
inst = inst.addToTransaction(trans) )

  inst._persist() is a private func called by Transaction to reset
instance to a usable post-transaction copy.

Example:

from SQLObject import Transaction
from Person import Person

t = Transaction()

a = Person.newForTransaction(t, ...)
b = Person(1).addToTransaction(t)

b.username = 'John'
b.addRole(1)
b.roles
# note: this queries the existing roles for Person(1)
# and mixes in the results.

t.commit()
# note: a and b are now fully functioning regular objects
# that can continue to be used. if possible, b is pulled from
# the cache, and both are now available in the cache as expected.
# t can also be reused at this point, but it has no memory about
# previous efforts. rollback after commit is obviously not supported.

Implementation Notes:

Internally, the transaction is implemented with an in-memory
DBConnection-subclass. This MemoryConnection is not generically
useful, it relies heavily on the previous connections of each of the
objects to provide for data it does not have (especially for joins),
and only maintains a diff from this for joins. Also, many DBAPI
methods are not implemented, as they are not relevant to the limited
accesses used by the new SQLObject methods.

I've tried to be as minimally invasive to SQLObject as feasible, with
only the following changes (beyond adding the three methods mentioned
above):

  __new__() now takes an additional argument 'useCache' to forcefully
avoid caching of a specific instance. This is for addToTransaction,
where we create a clean instance and then switch connections (but
don't want any record in the class/original connection cache)

  new() now sets inst._connection = kw['connection'] if a connection
is passed in. I'm not sure if this will break other expected
behavior, but it seems reasonable to me.

  RelatedJoin: performJoin, add, remove:  these all now use 'inst'
argument instead of self.callingClass to get a connection from.
Again, not sure if this will break expected behavior, but seems
reasonable to me. (I need this because, along with the previous
change, I am expecting true per-object connections when I ask for it.
:)

And that's it. I've attached the fully changed SQLObject directory,
only files with changes are SQLObject.py, Transaction.py (new), and
__init__.py (to import Transaction). Again, this is from CVS an hour
or two ago.

Questions? Comments? Let's go!

- Luke

Re: [SQLObject] thoughts on structure and components

[Bud P. B. <bu...@si...>]

On 08 May 2003 22:13:51 -0500
Ian Bicking <ia...@co...> wrote:

> Now, if I'm reading it right, this would be the most significant
> difference with SQLObject -- a mapping object is a separate from the
> class.  But why?  

Ian, I made some progress and I can more clearly answer to the
question above:

In this approach, relationships are instances managed by Mapping, not
part of the "class" (of the storable application object).  This way,
to keep object references from the relationship object to the
contained (from, to..) "table objects" (that I call ObjMap).  I can
also keep back-references from ObjMap to all the relations that
reference it.  

This way, I avoid (at least it seems at the moment) all problems of
circular dependencies, referencing to objects only by name, etc.  

--b


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] Col naming in MultipleJoin

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

On Sat, 2003-05-10 at 13:40, Luke Opperman wrote:
> My question is: what would you prefer the initialization for
> foreignKey's be? I'll throw out my idea, which is based on the fact
> that in general, we specify the *python* attribute name as the column
> name, and the dbName is optional:
> 
>   ForeignCol('person', foreignKey='Person')
> 
> would assume (based on Style object?) the dbname is person_id, and the
> direct ID python access stays as "personID" (since I think there are
> cases where there's justification for retaining immediate access to
> the actual key values).

I intended to do something like this.  Or maybe just:

KeyCol('Person')

Both person and personID then being implied.  I'm not sure whether I
should just replace KeyCol, or create a ForeignKey or ForeignCol class. 
I created a ForeignKey class in CVS, at least for now.

  Ian

Re: [SQLObject] Incorrect join column name

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

On Sun, 2003-05-11 at 17:55, Matt Goodall wrote:
[...example...]
> So far, so good. However when I have an existing Order (with id=1) and I
> "call" order.orderItems the following SQL is executed:
> 
> SELECT id FROM order_item WHERE ordr_id = 1
> 
> As you can see, ordr_id is wrong - it should be order_id.
> 
> I started trying to fix the error but realised that I don't actually
> know what to fix - the table creation code or the join code. i.e. should
> the created table's column be called ordr_id or should the join SQL use
> order_id?

I'm not sure what the proper behavior is here -- I think it's correct
currently (though for naming things like this there's no One Right
Way).  The default is that a foreign key column will be named
tablename_id, which is exactly what it does.  But you want to use the
automatically generated table name ("order"), not the explicit name
("ordr").  I think in that case you just need to be explicit, i.e.:

MultipleJoin('OrderItem', joinColumn='order_id')

  Ian

[SQLObject] Col.setName() error

[Matt G. <ma...@po...>]

Hi,

The current CVS code contains an error in Col.setName(), line 179:

    assert kw['name'] is None, ...

should be

    assert self.kw['name'] is None, ...

- Matt

Re: [SQLObject] Incorrect join column name

[Matt G. <ma...@po...>]

I should have mentioned ... this was using latest CVS HEAD and
PostgreSQL 7.3.

- Matt

On Sun, 2003-05-11 at 23:55, Matt Goodall wrote:
> Hi,
> 
> I've only recently started experimenting with SQLObject so please
> forgive me if this turns out to be complete nonsense ;-).
> 
> There seems to be a problem with the name that is generated for a join
> column when a class explicitly sets the name of the table (using
> _table). Here's an example:
> 
> class Order(SQLObject.SQLObject):
>     _table = 'ordr'
>     _columns = [
>         SQLObject.IntCol('number', dbName='nmbr'),
>         SQLObject.IntCol('customerID', foreignKey='Customer'),
>         ]
>     _joins = [SQLObject.MultipleJoin('OrderItem'),]
> 
> class OrderItem(SQLObject.SQLObject):
>     _columns = [
>         SQLObject.IntCol('orderID', foreignKey='Order'),
>         SQLObject.IntCol('productID', foreignKey='Product'),
>         SQLObject.IntCol('quantity'),
>         ]
> 
> (Ignore the Customer and Product classes - they're not relevant.)
> 
> >From the above, SQLObject creates the following tables:
> 
> CREATE TABLE ordr (
>     id serial NOT NULL,
>     nmbr integer,
>     customer_id integer
> );
> 
> CREATE TABLE order_item (
>     id serial NOT NULL,
>     order_id integer,
>     product_id integer,
>     quantity integer
> );
> 
> So far, so good. However when I have an existing Order (with id=1) and I
> "call" order.orderItems the following SQL is executed:
> 
> SELECT id FROM order_item WHERE ordr_id = 1
> 
> As you can see, ordr_id is wrong - it should be order_id.
> 
> I started trying to fix the error but realised that I don't actually
> know what to fix - the table creation code or the join code. i.e. should
> the created table's column be called ordr_id or should the join SQL use
> order_id?
> 
> If someone who understands what SQLObject's *should* be doing can tell
> me what to fix I will try to send a patch.
> 
> - Matt
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Incorrect join column name

[Matt G. <ma...@po...>]

Hi,

I've only recently started experimenting with SQLObject so please
forgive me if this turns out to be complete nonsense ;-).

There seems to be a problem with the name that is generated for a join
column when a class explicitly sets the name of the table (using
_table). Here's an example:

class Order(SQLObject.SQLObject):
    _table = 'ordr'
    _columns = [
        SQLObject.IntCol('number', dbName='nmbr'),
        SQLObject.IntCol('customerID', foreignKey='Customer'),
        ]
    _joins = [SQLObject.MultipleJoin('OrderItem'),]

class OrderItem(SQLObject.SQLObject):
    _columns = [
        SQLObject.IntCol('orderID', foreignKey='Order'),
        SQLObject.IntCol('productID', foreignKey='Product'),
        SQLObject.IntCol('quantity'),
        ]

(Ignore the Customer and Product classes - they're not relevant.)

>From the above, SQLObject creates the following tables:

CREATE TABLE ordr (
    id serial NOT NULL,
    nmbr integer,
    customer_id integer
);

CREATE TABLE order_item (
    id serial NOT NULL,
    order_id integer,
    product_id integer,
    quantity integer
);

So far, so good. However when I have an existing Order (with id=1) and I
"call" order.orderItems the following SQL is executed:

SELECT id FROM order_item WHERE ordr_id = 1

As you can see, ordr_id is wrong - it should be order_id.

I started trying to fix the error but realised that I don't actually
know what to fix - the table creation code or the join code. i.e. should
the created table's column be called ordr_id or should the join SQL use
order_id?

If someone who understands what SQLObject's *should* be doing can tell
me what to fix I will try to send a patch.

- Matt

Re: [SQLObject] Problems with str() on SQLObjects

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

On Sat, 2003-05-10 at 09:57, Simen Brekken wrote:
> Where Entry is an SQLObject:
> 
> -- BEGIN entry.py --
> class Entry(SQLObject):
>  _columns = [IntCol('date', default=None), Col('content',
> default=None),
> IntCol('mood', default=5)]
>  _connection = SQLiteConnection('C:/Home/Projects/blog/blog.db',
> debug=1)
> 
>  def content(self):
>   return {'date': self.date, 'content': self.content, 'mood':
> self.mood}
> -- END entry.py --

This is where your bug is -- your content definition overrides your
content column.  So when you do a repr, it tries to construct:

<Entry (self.id) date=(self.date) content=(self.content)
mood=(self.mood)> [substituting (self.xxx), of course)

Because you redefined it, self.content is now a method.  Methods' repr
is <bound method (method name) of (repr(object-method-is-bound-to)>.  So
we get an infinite loop.

Obviously the resulting loop is not a very good indication of the
underlying problem.  I'm not sure what the best resolution is -- maybe
SQLObject should make sure that there isn't a method shadowing any
column, since I don't think there's any reason you'd want to do that.

In this case you should rename the content() method to perhaps
_get_allContent() or something.

  Ian

Re: [SQLObject] Col naming in MultipleJoin

[Luke O. <lu...@me...>]

Quoting Nick <ni...@dd...>:

> see attached patch.  it basically puts the ID on for you instead of
> you
> having to do it in Col() so it doesn't break anything.  There's no
> reason to change the functionality other than I don't like forced
> naming
> conventions in this way :)

Yep, that's the condensed version of what I was suggesting: turn it
around, so that the column names you define are all the *python*
accessors, and the fact that it's a key is tacked on elsewhere (or
explicit, as dbName sometimes must be). (This makes the assumption
that I think we both share, that the 'correct' pythonic accessor is
directly to the object, and the secondary one is to the ID key
value.)

(although I personally wouldn't hardcode it into Col() either way,
rather make it a subclass of Col; your patch is minimally
code-invasive, but very disruptive of existing code. But I realize
it's mostly for private consumption only. :)

I suppose if I were writing ForeignCol as described in my last post,
I'd go one step further, and remove the duplicate verbage (which
exists whether it is ForeignCol or KeyCol) of saying 'foreignKey=':

 ForeignKey('mother', to='Person')

in the shortest form.

possible braindead implementation, requiring no changes to existing
Col implementation, ignoring directAttr idea:

class ForeignCol(Col):
  def __init__(self, name, **kw):
    to = popKey(kw, 'to')
    if to:
      kw['foreignKey'] = to
    newName = name + 'ID'
    Col.__init__(self, newName, **kw)

Re: [SQLObject] Col naming in MultipleJoin

[Nick <ni...@dd...>]

see attached patch.  it basically puts the ID on for you instead of you
having to do it in Col() so it doesn't break anything.  There's no
reason to change the functionality other than I don't like forced naming
conventions in this way :)

Nick

On Sat, 2003-05-10 at 13:40, Luke Opperman wrote:
> Quoting Nick <ni...@dd...>:
> >  The fact that you have to call a column somethingid is hardcoded
> > in SQLObject.  I don't particularly like it, since it's clear in
> > the Col definition that this is a foreign key.  I don't particularly
> > see the downside in having to say pn.Person.id vs. pn.PersonID.
> > I think it's more clear if you're really making an object oriented
> > model.
> 
> Hmm, would you expand on this slightly? In our usage, yes, we almost
> always use pn.Person.id, and .
> 
> The problem is that _columns/_joins defines the structure of the
> database, and the pythonic access mechanisms appear by magic *for
> some columns, and for all joins*. (somewhere around here I wrote up a
> one-page summary of magic that happens, maybe it'd be useful in the
> docs? I think it's all there already, this is just a summary of
> 'unexpected' things, to have people know they don't need to do
> personID=myPeep.id, for instance.)
> 
> My question is: what would you prefer the initialization for
> foreignKey's be? I'll throw out my idea, which is based on the fact
> that in general, we specify the *python* attribute name as the column
> name, and the dbName is optional:
> 
>   ForeignCol('person', foreignKey='Person')
> 
> would assume (based on Style object?) the dbname is person_id, and the
> direct ID python access stays as "personID" (since I think there are
> cases where there's justification for retaining immediate access to
> the actual key values).
> 
>   ForeignCol('person', foreignKey='Person, dbName='person',
> directAttr='personId')
> 
> Not sure on the nam 'directAttr', but this would be the mechanism for
> overriding the direct python access name.
> 
> This doesn't have to require a change to existing code, as all other
> columns could still take the foreignKey argument; this column-type is
> just a shortcut that may make more sense for some people. Depending
> on what people say, this could become KeyCol, or not (for
> backwards-compatibility issues).
> 
> Thoughts?
> 
> - Luke
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Col naming in MultipleJoin

[Luke O. <lu...@me...>]

Quoting Nick <ni...@dd...>:
>  The fact that you have to call a column somethingid is hardcoded
> in SQLObject.  I don't particularly like it, since it's clear in
> the Col definition that this is a foreign key.  I don't particularly
> see the downside in having to say pn.Person.id vs. pn.PersonID.
> I think it's more clear if you're really making an object oriented
> model.

Hmm, would you expand on this slightly? In our usage, yes, we almost
always use pn.Person.id, and .

The problem is that _columns/_joins defines the structure of the
database, and the pythonic access mechanisms appear by magic *for
some columns, and for all joins*. (somewhere around here I wrote up a
one-page summary of magic that happens, maybe it'd be useful in the
docs? I think it's all there already, this is just a summary of
'unexpected' things, to have people know they don't need to do
personID=myPeep.id, for instance.)

My question is: what would you prefer the initialization for
foreignKey's be? I'll throw out my idea, which is based on the fact
that in general, we specify the *python* attribute name as the column
name, and the dbName is optional:

  ForeignCol('person', foreignKey='Person')

would assume (based on Style object?) the dbname is person_id, and the
direct ID python access stays as "personID" (since I think there are
cases where there's justification for retaining immediate access to
the actual key values).

  ForeignCol('person', foreignKey='Person, dbName='person',
directAttr='personId')

Not sure on the nam 'directAttr', but this would be the mechanism for
overriding the direct python access name.

This doesn't have to require a change to existing code, as all other
columns could still take the foreignKey argument; this column-type is
just a shortcut that may make more sense for some people. Depending
on what people say, this could become KeyCol, or not (for
backwards-compatibility issues).

Thoughts?

- Luke

Re: [SQLObject] Col naming in MultipleJoin

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

On Sat, 2003-05-10 at 08:28, deelan wrote:
> infact if i change phonenumber "PersonID" with "PersonId" sqlobject 
> throws out an error:"All foreign key columns must end with 'ID'"
> perhaps i'm missing something obvious here.

That was a fairly arbitrary requirement.  The naming requirement still
exists in CVS, but it's case-insensitive, which would fix your problem. 
So feel free to remove or modify that assert, since the behavior will be
fixed for 0.4.

> linked to this issue adding a new phonenumber to
> person "p" instance requies the oddly named "PersonID"
> 
> p = Person(1)
> 
> this fails:
> pn = PhoneNumber.new(phone='666', type='home', PersonId=p.id)
> 
> this works:
> pn = PhoneNumber.new(phone='666', type='home', PersonID=p.id)

Because you are defining an attribute you named PhoneNumber.PersonID
(which happens to equate to number.PersonId in the database).  So even
if you named it that against your will ;), it's just being consistent.

  Ian

Re: [SQLObject] Col naming in MultipleJoin

[Nick <ni...@dd...>]

On Sat, 2003-05-10 at 13:03, deelan wrote:
> Nick wrote:
> >>this fails:
> >>pn = PhoneNumber.new(phone='666', type='home', PersonId=p.id)
> >>
> >>this works:
> >>pn = PhoneNumber.new(phone='666', type='home', PersonID=p.id)
> > 
> > 
> > Correct; the parameters in SQLObject methods match to the first argument
> > to Col, the Pythonic column name, not dbName, the column name in the
> > database.
> 
> that's fine, but what i would like to know is why i can't name
> the Col "PersonId"  and i have to call it "PersonID", this happens
> both in the pythonic column name and in the DB column name.

No, the dbName can be anything.  It doesn't matter what it's called in
the database as long as you use it in the dbName parameter.  The fact
that you have to call a column somethingid is hardcoded in SQLObject.  I
don't particularly like it, since it's clear in the Col definition that
this is a foreign key.  I don't particularly see the downside in having
to say pn.Person.id vs. pn.PersonID.  I think it's more clear if you're
really making an object oriented model.  So I altered my local code to
do this and maintain a patch against CVS.

Nick

Re: [SQLObject] Col naming in MultipleJoin

[deelan <de...@in...>]

Nick wrote:
>>this fails:
>>pn = PhoneNumber.new(phone='666', type='home', PersonId=p.id)
>>
>>this works:
>>pn = PhoneNumber.new(phone='666', type='home', PersonID=p.id)
> 
> 
> Correct; the parameters in SQLObject methods match to the first argument
> to Col, the Pythonic column name, not dbName, the column name in the
> database.

that's fine, but what i would like to know is why i can't name
the Col "PersonId"  and i have to call it "PersonID", this happens
both in the pythonic column name and in the DB column name.

am i missing something?

thanks for your support.

Re: [SQLObject] Col naming in MultipleJoin

[Nick <ni...@dd...>]

On Sat, 2003-05-10 at 08:28, deelan wrote:
> this fails:
> pn = PhoneNumber.new(phone='666', type='home', PersonId=p.id)
> 
> this works:
> pn = PhoneNumber.new(phone='666', type='home', PersonID=p.id)

Correct; the parameters in SQLObject methods match to the first argument
to Col, the Pythonic column name, not dbName, the column name in the
database.

> p = Person(1)
> pn = PhoneNumber.new(phone='666', type='home', Person=p)

That would be preferred for readability.

Nick

[SQLObject] Col naming in MultipleJoin

[deelan <de...@in...>]

hi there,

i'm starting to play around with sqlobject 0.3, i'm following the
html pages and trying out things described in the manual. i'm having 
troubles to correctly name a foreign key column using multiplejoin.

for example, using this two classes:

class PhoneNumber(SQLObject):
     """Phone number"""

     _table = "number"
     _idName = "NumberId"
     _columns = [
         Col("PersonID", dbName="PersonId", foreignKey="Person"),
         Col("phone", dbName="Phone"),
         Col("type", dbName="PhoneType")
         ]

class Person(SQLObject):
     """Person in address book"""

     _table = "person"
     _idName = "PersonId"
     _columns = [
         Col("firstName", dbName="FName"),
         Col("lastName", dbName="LName"),
         ]
     _joins = [MultipleJoin('PhoneNumber', joinColumn='PersonId')]

in phonenumber class, "PersonID" column must named "PersonID" with 
correct "ID" case both in the class and in the DB, it seems to ignore 
dbName="" value i specify in the col constructor. to maintain 
consistency with my db schema it would be better to name field as 
PersonId (see Person class).

infact if i change phonenumber "PersonID" with "PersonId" sqlobject 
throws out an error:"All foreign key columns must end with 'ID'"
perhaps i'm missing something obvious here.

linked to this issue adding a new phonenumber to
person "p" instance requies the oddly named "PersonID"

p = Person(1)

this fails:
pn = PhoneNumber.new(phone='666', type='home', PersonId=p.id)

this works:
pn = PhoneNumber.new(phone='666', type='home', PersonID=p.id)

please note, you access person's unique id with p.id (lowercase) but
you have to name Col named "PersonID" ;(

any help would be appreciated.

thanks.

PS:
BTW i've just found that this works:

p = Person(1)
pn = PhoneNumber.new(phone='666', type='home', Person=p)

Re: [SQLObject] Problems with str() on SQLObjects

[Simen B. <si...@lu...>]

I get this message afer it's been looping for a while:

RuntimeError: maximum recursion depth exceeded

The code producing it is a function called xmlrepr which basically takes
some basic python types and turns them into an xml document:

-- BEGIN xmlify.py --
from types import ListType, DictionaryType, InstanceType

def xmlrepr(object, name):
 if type(object) =3D=3D ListType:
  xml =3D "<%s>" % name
  for item in object:
   xml+=3D xmlrepr(item, "item")

  xml =3D xml + "</%s>" % name
  return xml

 elif type(object) =3D=3D DictionaryType:
  xml =3D "<%s>" % name
  for (key, value) in object.items():
   xml+=3D xmlrepr(value, key)

  xml =3D xml + "</%s>" % name
  return xml
 else:
  return "<%s>%s</%s>" % (name, object, name)
-- END xmlify.py --

The code invoking this is here:

-- BEGIN Main.py --
 def list(self):
  """Lists the current entries."""
  entries =3D []
  for entry in Entry.select('all'):
   entries.append(entry.content())

  self.model =3D entries
-- END --

Where Entry is an SQLObject:

-- BEGIN entry.py --
class Entry(SQLObject):
 _columns =3D [IntCol('date', default=3DNone), Col('content', =
default=3DNone),
IntCol('mood', default=3D5)]
 _connection =3D SQLiteConnection('C:/Home/Projects/blog/blog.db', =
debug=3D1)

 def content(self):
  return {'date': self.date, 'content': self.content, 'mood': self.mood}
-- END entry.py --

Hope that helped :)

----- Original Message -----=20
From: "Brad Bollenbach" <br...@bb...>
To: <si...@lu...>
Sent: Saturday, May 10, 2003 4:42 PM
Subject: Re: [SQLObject] Problems with str() on SQLObjects


> Date: Sat, 10 May 2003 09:14:52 -0500
> From: Brad Bollenbach <br...@bb...>
> To: sql...@li...
> Subject: Re: [SQLObject] Problems with str() on SQLObjects
>
> On 05/10/03 14:49, Simen Brekken wrote:
> > Hi, I'm working on an MVC app and I'm using SQLObject for the Model =
part
of it, however I'm having some problems getting the values of normal =
string
columns:
> >
> >   File "...\xmlify.py", line 22, in xmlrepr
> >     return "<"+name+">"+str(object)+"</"+name+">"
> >   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", =
line
834, in __repr__
> >     return '<%s %i %s>' \
> >   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", =
line
843, in _reprItems
> >     r =3D repr(value)
> >   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", =
line
834, in __repr__
> >
> > It runs into an infinite loop! 'object'. The strange thing is that =
this
only happens to Col() or StringCol() types, IntCol() works fine.
>
> Can you post the error message after the traceback or is it just a
> simple KeyboardInterrupt from getting out of the infinite loop (if in
> fact it's an infinite loop)?
>
> Also, a simple test case to reproduce the bug will shorten the
> distance between problem and solution.
>
> --=20
> Brad Bollenbach
> BBnet.ca
>
>

=20
___
SIMEN BREKKEN / born to synthesize.

Re: [SQLObject] Problems with str() on SQLObjects

[Brad B. <br...@bb...>]

On 05/10/03 14:49, Simen Brekken wrote:
> Hi, I'm working on an MVC app and I'm using SQLObject for the Model part of it, however I'm having some problems getting the values of normal string columns:
> 
>   File "...\xmlify.py", line 22, in xmlrepr
>     return "<"+name+">"+str(object)+"</"+name+">"
>   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line 834, in __repr__
>     return '<%s %i %s>' \
>   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line 843, in _reprItems
>     r = repr(value)
>   File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line 834, in __repr__
> 
> It runs into an infinite loop! 'object'. The strange thing is that this only happens to Col() or StringCol() types, IntCol() works fine.

Can you post the error message after the traceback or is it just a
simple KeyboardInterrupt from getting out of the infinite loop (if in
fact it's an infinite loop)?

Also, a simple test case to reproduce the bug will shorten the
distance between problem and solution.

-- 
Brad Bollenbach
BBnet.ca

[SQLObject] Problems with str() on SQLObjects

[Simen B. <si...@lu...>]

Hi, I'm working on an MVC app and I'm using SQLObject for the Model part =
of it, however I'm having some problems getting the values of normal =
string columns:

  File "...\xmlify.py", line 22, in xmlrepr
    return "<"+name+">"+str(object)+"</"+name+">"
  File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line =
834, in __repr__
    return '<%s %i %s>' \
  File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line =
843, in _reprItems
    r =3D repr(value)
  File "C:\Utils\Python\Lib\site-packages\SQLObject\SQLObject.py", line =
834, in __repr__

It runs into an infinite loop! 'object'. The strange thing is that this =
only happens to Col() or StringCol() types, IntCol() works fine.

___
SIMEN BREKKEN / born to synthesize.

Re: [SQLObject] Clause-less select()'s

[Luke O. <lu...@me...>]

You're looking for the special-case clause 'all':

Class.select('all')

- Luke

Quoting Simen Brekken <si...@lu...>:

> I may have missed something fundamental, but I can't seem to find a
> way to fetch all records from a table without specifying a clause
> for the Class.select() method. What method am I looking for? :)
>
> ___
> SIMEN BREKKEN / born to synthesize.
>


--
 i find your contempt for naked feet curious.

[SQLObject] Clause-less select()'s

[Simen B. <si...@lu...>]

I may have missed something fundamental, but I can't seem to find a way =
to fetch all records from a table without specifying a clause for the =
Class.select() method. What method am I looking for? :)
=20
___
SIMEN BREKKEN / born to synthesize.