sqlobject-discuss — All things SQLObject-related

[SQLObject] Patch to allow foreignKey objects in selectBy

[David M. C. <da...@da...>]

I submitted a patch for this to sf.net:

http://myturl.com/0018O

Dave Cook

Re: [SQLObject] specifying a connection object at runtime.

[Markus J. <mar...@ya...>]

On Wed, 2004-09-22 at 10:47, paul k=F6lle wrote:
> Ian Bicking wrote:
> >> class AuthorTable:
> >>
> >>     def __init__(self, connection):
> >>         Author._connection =3D connection
> >>         Author.createTable(ifNotExists=3DTrue) =20
> >>
> >> def createAuthorTable(connection):
> >>     AuthorTable(connection)
> >>            =20
> >> createAuthorTable(connectionForURI('mysql://markus:eagle@localhost/boo=
ks'))=20
> >>
> >>
> >> a1 =3D Author(firstName =3D "J.R.R.", lastName =3D
> >> "Tolkien")
> >=20
> >=20
> > Yes, this is fine -- you can assign to ._connection as you set up the=20
> > classes.  The AuthorTable class seems a little odd to me -- I'd probabl=
y=20
> > do it more like:
> This strikes me too. At first I also made those ...Table: classes but=20
> discovered there is no real use for them since the SQLObject classes are=20
> the tables themselves. It is very strange at first not to have a=20
> distinct object for "tables". It would be nice to address this issue in=20
> the article since it illustrates the (to be changed) object vs.=20
> relational mindset (Markus?).

I think I will mention this in the article.=20
this was just an example how it could be done. in the end=20
the read will have to decide for herself/himself if she/he wants
to do it this way. this also depends on the application of the reader.

thanks for your comments.

I will inform you when the article is published, but this will probably
not happen before 2005.

Markus

>=20
> just my 0.02=A4
>   Paul
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Name of MultipleJoin attribute being ignored.

[David M. C. <da...@da...>]

On Fri, Sep 24, 2004 at 11:00:24AM -0500, Ian Bicking wrote:

> I haven't had a chance to look at MultipleJoin closely, to really figure 
> out what it's problem is, but I did (rather blindly) apply a patch sent 
> by Cyril.  It's not in 0.6, but it's in the repository, maybe it will 
> help you.

Just tried out the SVN sqlobject and see the same thing.

And even weirder:

  In [10]: [j.joinMethodName for j in Composer._joins]
  Out[10]: ['children']

But it *does* work if I explictly specify the joinMethodName: 

  children = MultipleJoin('Work', joinMethodName='children')

Thanks, BTW, for the change that allows foreignKeys to be used when
inserting, rather than having to use the ID.  Also it's great to now be able
to use multiple keys in selectBy (though that method does not understand
foreignKeys yet).

Dave Cook

Re: [SQLObject] Name of MultipleJoin attribute being ignored.

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

I haven't had a chance to look at MultipleJoin closely, to really figure 
out what it's problem is, but I did (rather blindly) apply a patch sent 
by Cyril.  It's not in 0.6, but it's in the repository, maybe it will 
help you.

David M. Cook wrote:
> I like to give my MultipleJoin columns the name 'children' to give a uniform
> way to access the associated objects.  But SQLObject 0.6 ignores my class
> attribute name:
> 
>   from sqlobject import *
>   
>   __connection__ = 'sqlite:///tmp/test.db'
>   
>   class Composer(SQLObject):
>   
>       name = StringCol()
>       children = MultipleJoin('Work')
>   
>   class Work(SQLObject):
>       
>       composer = ForeignKey('Composer')
>       title = StringCol()
>   
>   for klass in Composer, Work:
>       klass.dropTable(ifExists=True)
>       klass.createTable(ifNotExists=True)
>   
>   c = Composer(name='Beethoven, Ludwig van')
>   w = Work(composer=c, title='Symphony No. 7')
>   
>   print c.works
>   print c.children
> 
> This gives the result:
> 
> [<Work 1 composerID=1 title='Symphony No. 7'>]
> Traceback (most recent call last):
>   File "<stdin>", line 23, in ?
>   AttributeError: 'Composer' object has no attribute 'children'
>   
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss


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

[SQLObject] Name of MultipleJoin attribute being ignored.

[David M. C. <da...@da...>]

I like to give my MultipleJoin columns the name 'children' to give a uniform
way to access the associated objects.  But SQLObject 0.6 ignores my class
attribute name:

  from sqlobject import *
  
  __connection__ = 'sqlite:///tmp/test.db'
  
  class Composer(SQLObject):
  
      name = StringCol()
      children = MultipleJoin('Work')
  
  class Work(SQLObject):
      
      composer = ForeignKey('Composer')
      title = StringCol()
  
  for klass in Composer, Work:
      klass.dropTable(ifExists=True)
      klass.createTable(ifNotExists=True)
  
  c = Composer(name='Beethoven, Ludwig van')
  w = Work(composer=c, title='Symphony No. 7')
  
  print c.works
  print c.children

This gives the result:

[<Work 1 composerID=1 title='Symphony No. 7'>]
Traceback (most recent call last):
  File "<stdin>", line 23, in ?
  AttributeError: 'Composer' object has no attribute 'children'
  

[SQLObject] Postgres connection close on exit

[Menno S. <me...@fr...>]

Hi,

I've just submitted a simple patch that causes PostgresConnection to 
close any underlying psycopg connections on exit.

Before I did this I was seeing lots of postgres log entries like this:
      "pq_recvbuf: unexpected EOF on client connection"
These occured whenever a program using SQLObject exited. Fairly harmless 
but was creating a lot of noise in the logs.

Patch can be found at:
http://sourceforge.net/tracker/index.php?func=detail&aid=1033807&group_id=74338&atid=540674

Does it look sane/safe?

Please CC me on any replies as I'm not a list subscriber.

Regards,
Menno


Scanned by the NetBox from NetBox Blue
(http://netboxblue.com/)

Re: [SQLObject] Close connections

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

SQLObject has built in connection pooling which makes closing specific
connections non-trivial.  I have written some documentation on different
approaches to managing connections in SQLObject here that may help:
http://wiki.sqlobject.org/connections.html

-Charles.

----- Original Message -----=20
From: "Man 5940" <ma...@gm...>
To: <sql...@li...>
Sent: Thursday, September 23, 2004 9:13 AM
Subject: [SQLObject] Close connections


Can I close the database connections? I developing a wxPython +
SQLobject application but I don=B4t close the database connections.


Thanks


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
sqlobject-discuss mailing list
sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Close connections

[Man 5. <ma...@gm...>]

Can I close the database connections? I developing a wxPython +
SQLobject application but I don=B4t close the database connections.


Thanks

[SQLObject] SQLObject 0.5.3: patch for _mungeOrderBy

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

Hello!

   I want to remind you of your own patch (attached).

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

[SQLObject] Thai Handicrafts : Lamp, Umbrella, Mango wood, Candle, Saa (mulberry) paper

[Siam P. <mar...@si...>]

Thai Handicrafts [ www=2Esiamproduct=2Enet ] : Lamp, Candle, Umbrella, Man=
go wood, Saa (mulberry) paper

Re: [SQLObject] SQLObject 0.6 (and 0.5.3)

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

Brian Ray wrote:
> Good Job!
> 
> Are there any backward compatibility considerations when users are  
> moving from .5 to .6? Thought I would ask in advance.

The only specific things are the SQLObject->sqlobject renaming (which is 
easy to apply), and the change in creating and fetching rows (which is a 
little annoying, since it's a swap).  The other changes shouldn't really 
effect your code.

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

[SQLObject] Plans from here

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

I kind of put 0.6 out just so it was there, especially since it has some 
small but pervasive API changes, and to give people a chance to move 
over to that.  And it's just been too long.

My short-term goals from here:

* Integrate some of the patches that are out there.  Indexing, distinct, 
and maybe a couple others.  I'll look on SourceForge for the patches; if 
there's something that's not there that you'd like me to look at, it 
would probably be good to add it there.

* Introduce a sqlmeta object; this is going to be a companion object for 
SQLObject instances, that will contain metadata, and provide a good 
introspection interface.  Class definitions will start to look like:

class MyClass(SQLObject):
     class sqlmeta:
         table = 'my_class_table'
         ...
     aColumn = StringCol()


And so on.  The sqlmeta class definition will be kind of incorrect, as 
it's just a way of passing parameters; when you access aMyClass.sqlmeta 
you'll get getting a subclass of sqlobject.SQLMeta; but they'll be a 
parrallel, in that the parameters you set (or can set) in the 
constructor will be available in the sqlmeta instance.  I'll be more 
careful about read-only attributes and the sort, so this should be a 
good introspection interface.  And we'll get rid of all the leading 
underscores (_table, _connection, etc).

* Make *Col objects into descriptors.  This is mostly an internal 
change, but I hope to simplify the SQLObject class significantly.

* Col objects will be definable as classes, like:

class MyClass(SQLObject):
     class aColumn(StringCol):
         dbName = 'ABadColumnName'
         def get(self, dbGetter):
             value = dbGetter()
             return value.lower()

And so on.  This is where things like onDelete can go, and just a 
general place to hang hooks.  This will be equivalent to:

class MyClass(SQLObject):
     aColumn = StringCol(dbName='ABadColumnName',
         get=lambda self, dbGetter: dbGetter().lower())

And the current form won't be deprecated in any way (it'll usually be 
easier to type anyway), but the class form will be more comfortable when 
you're doing things like adding methods to a column.


Anyway, that's the order I'm thinking of tackling things in.  I've been 
actively wanting to do these things for the last week or two, but I 
didn't want to mess with things before making an 0.6 release, since it 
was overdue and I didn't want to destabalize the code.  I forget that 
it's really not that hard to make a release.  Hopefully between these 
steps I'll make more releases.

Cheers,
   Ian

Re: [SQLObject] SQLObject 0.6 (and 0.5.3)

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

Marcin Wojdyr wrote:
> On Wed, 22 Sep 2004, Ian Bicking wrote:
>>For a more complete list, please see the news: 
>>http://sqlobject.org/docs/News.html
> 
> 
> And there: 
> """
> Col constructors now support cascade: [...]  The constraints 
> are only implemented in the DBMS, not in SQLObject (i.e., they will not 
> work in databases like MySQL and SQLite)."
> """
> 
> I mentioned in 
> http://sourceforge.net/mailarchive/message.php?msg_id=9497517
> that it works in MySQL. SQLObjects throws an SQLObjectIntegrityError
> when I try to delete constrained row. Is this an experimental feature?
> Should I expect that it will be removed in future?

It is a bit experimental.  It was added by Sidnei de Silva, and I 
haven't fully thought about what it implies.

My goal is to change columns so that they receive event notification, 
e.g., an onDelete method is called.  Well, joins as well, since in this 
case the MultipleJoin would be doing the cascade.  Which is kind of the 
opposite of cascade, which is defined on the ForeignKey.  Hm... I'm 
still thinking it through.  So... I guess we actually need events across 
SQLObject instances; in this case, the class with the ForeignKey wants 
to get events from the class it's joined to, or more specifically a 
specific instance is interested in the events of some other instance. 
But lazily, since we obviously don't want to bring in the joined class 
just to register the event, because then fetching one object could pull 
in a huge set of objects.

Well, it's there.  I think the interface that's in SQLObject will 
probably stay, but the semantics will change some.

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

[SQLObject] Re: SQLObject 0.6

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

Oleg Broytmann wrote:
> Hello.
> 
> On Wed, Sep 22, 2004 at 01:13:35AM -0500, Ian Bicking wrote:
> 
>>To fetch objects from the database, use MyClass.get(id) (instead of 
>>MyClass(id)).  To create/insert objects, use MyClass(col=value, ...) 
>>(instead of MyClass.new(col=value, ...)).
> 
> 
>    I alway wanted to know - why?! Why not MyClass.get(id) and
> MyClass.new(**values)?

Mostly so that it looks like other classes, where you create an object 
with MyClass(...).  The underlying code was a bit more complicated too, 
which made me feel like I was going out of my way to do things backwards.

   Ian

[SQLObject] Re: SQLObject 0.6

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

Hello.

On Wed, Sep 22, 2004 at 01:13:35AM -0500, Ian Bicking wrote:
> To fetch objects from the database, use MyClass.get(id) (instead of 
> MyClass(id)).  To create/insert objects, use MyClass(col=value, ...) 
> (instead of MyClass.new(col=value, ...)).

   I alway wanted to know - why?! Why not MyClass.get(id) and
MyClass.new(**values)?

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

Re: [SQLObject] SQLObject 0.6 (and 0.5.3)

[David M. C. <da...@da...>]

On Wed, Sep 22, 2004 at 01:05:00PM +0200, Marcin Wojdyr wrote (quoting the
docs):

> """
> Col constructors now support cascade: [...]  The constraints 
> are only implemented in the DBMS, not in SQLObject (i.e., they will not 
> work in databases like MySQL and SQLite)."
> """

I'm not sure I understand this.  Cascading is only done in the DBM?  What if
I try to update a referenced SQLObject that has been deleted from the DBM?

Also, will this complain if I try to use cascade with an SQLite connection, or
just ignore it?

Dave Cook

Re: [SQLObject] SQLObject 0.6 (and 0.5.3)

[Brian R. <br...@se...>]

Good Job!

Are there any backward compatibility considerations when users are  
moving from .5 to .6? Thought I would ask in advance.

On Sep 22, 2004, at 1:14 AM, Ian Bicking wrote:

> I've made a long-overdue release of SQLObject 0.6, and a final bug-fix  
> release for the 0.5 series.
>
> What is SQLObject
> =================
>
> SQLObject is an object-relational mapper.  Your database tables are  
> described as classes, and rows are instances of those classes.  
> SQLObject is meant to be easy to use and quick to get started with.
>
> SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,  
> and Firebird.  It also has newly added support for Sybase and MaxDB  
> (also known as SAPDB).
>
>
> Where is SQLObject
> ==================
>
> Site:
> http://sqlobject.org
>
> Mailing list:
> https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss
>
> Archives:
> http://news.gmane.org/gmane.comp.python.sqlobject
>
> Download:
> http://prdownloads.sourceforge.net/sqlobject/SQLObject-0.6.tar.gz? 
> download
>
> News and changes:
> http://sqlobject.org/docs/News.html
>
>
> What's New
> ==========
>
> In 0.5.3: some small bug fixes, and an important fix when iterating  
> over selects in threaded environments.
>
> In 0.6:
>
> The "SQLObject" module has been renamed "sqlobject".
>
> To fetch objects from the database, use MyClass.get(id) (instead of  
> MyClass(id)).  To create/insert objects, use MyClass(col=value, ...)  
> (instead of MyClass.new(col=value, ...)).
>
> Better support for constraints.
>
> Connections given using URLs, like 'mysql://user:pass@localhost/dbname'
>
> Optional lazy updates -- SQL UPDATE executed only on demand.
>
> For a more complete list, please see the news:  
> http://sqlobject.org/docs/News.html
>
> -- 
> Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] SQLObject 0.6 (and 0.5.3)

[Marcin W. <wo...@un...>]

Hi,

On Wed, 22 Sep 2004, Ian Bicking wrote:

> For a more complete list, please see the news: 
> http://sqlobject.org/docs/News.html

And there: 
"""
Col constructors now support cascade: [...]  The constraints 
are only implemented in the DBMS, not in SQLObject (i.e., they will not 
work in databases like MySQL and SQLite)."
"""

I mentioned in 
http://sourceforge.net/mailarchive/message.php?msg_id=9497517
that it works in MySQL. SQLObjects throws an SQLObjectIntegrityError
when I try to delete constrained row. Is this an experimental feature?
Should I expect that it will be removed in future?

Marcin

-- 
Marcin Wojdyr                       http://www.unipress.waw.pl/~wojdyr/

Re: [SQLObject] specifying a connection object at runtime.

[<pa...@su...>]

Ian Bicking wrote:
>> class AuthorTable:
>>
>>     def __init__(self, connection):
>>         Author._connection =3D connection
>>         Author.createTable(ifNotExists=3DTrue) =20
>>
>> def createAuthorTable(connection):
>>     AuthorTable(connection)
>>            =20
>> createAuthorTable(connectionForURI('mysql://markus:eagle@localhost/boo=
ks'))=20
>>
>>
>> a1 =3D Author(firstName =3D "J.R.R.", lastName =3D
>> "Tolkien")
>=20
>=20
> Yes, this is fine -- you can assign to ._connection as you set up the=20
> classes.  The AuthorTable class seems a little odd to me -- I'd probabl=
y=20
> do it more like:
This strikes me too. At first I also made those ...Table: classes but=20
discovered there is no real use for them since the SQLObject classes are=20
the tables themselves. It is very strange at first not to have a=20
distinct object for "tables". It would be nice to address this issue in=20
the article since it illustrates the (to be changed) object vs.=20
relational mindset (Markus?).

just my 0.02=80
  Paul

[SQLObject] SQLObject 0.6 (and 0.5.3)

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

I've made a long-overdue release of SQLObject 0.6, and a final bug-fix 
release for the 0.5 series.

What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are 
described as classes, and rows are instances of those classes. 
SQLObject is meant to be easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and 
Firebird.  It also has newly added support for Sybase and MaxDB (also 
known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
http://prdownloads.sourceforge.net/sqlobject/SQLObject-0.6.tar.gz?download

News and changes:
http://sqlobject.org/docs/News.html


What's New
==========

In 0.5.3: some small bug fixes, and an important fix when iterating over 
selects in threaded environments.

In 0.6:

The "SQLObject" module has been renamed "sqlobject".

To fetch objects from the database, use MyClass.get(id) (instead of 
MyClass(id)).  To create/insert objects, use MyClass(col=value, ...) 
(instead of MyClass.new(col=value, ...)).

Better support for constraints.

Connections given using URLs, like 'mysql://user:pass@localhost/dbname'

Optional lazy updates -- SQL UPDATE executed only on demand.

For a more complete list, please see the news: 
http://sqlobject.org/docs/News.html

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

Re: [SQLObject] specifying a connection object at runtime.

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

Markus Jais wrote:
> Hola
> 
> I have another SQLObject question.
> 
> this is my code:
> ---
> from sqlobject import *
> 
> class Author(SQLObject):
>     
>     firstName = StringCol()
>     lastName  = StringCol()
> 
> class AuthorTable:
> 
>     def __init__(self, connection):
>         Author._connection = connection
>         Author.createTable(ifNotExists=True)   
> 
> 
> def createAuthorTable(connection):
>     AuthorTable(connection)
>     
>     
>     
> createAuthorTable(connectionForURI('mysql://markus:eagle@localhost/books'))
> 
> a1 = Author(firstName = "J.R.R.", lastName =
> "Tolkien")

Yes, this is fine -- you can assign to ._connection as you set up the 
classes.  The AuthorTable class seems a little odd to me -- I'd probably 
do it more like:

tableClasses = [Author]
def createTables(connection):
     for tableClass in tableClasses:
         tableClass._connection = connection
         tableClass.createTable(ifNotExists=True)

But maybe that's just a matter of taste.

> the reason for this is that I want a generic modul
> about authors and I want to specify the connection
> Object at runtime, for example when I want
> to use PostgreSQL.
> 
> the code works but I would like to know
> if it has any flaws I do not see.
> 
> the reason for my question is, that I am
> preparing an article about Object Relational Mapping
> in Python for a german magazine. and
> the main focus will be on SQLObject with 2 or
> 3 simple Examples.
> I really like SQLObject and maybe the article
> helps to get more people interested in SQLObject.
> and I do not want to have any serious errors
> in my examples.

Cool, if you want to run any other scripts by, please do.

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

[SQLObject] specifying a connection object at runtime.

[Markus J. <mar...@ya...>]

Hola

I have another SQLObject question.

this is my code:
---
from sqlobject import *

class Author(SQLObject):
    
    firstName = StringCol()
    lastName  = StringCol()

class AuthorTable:

    def __init__(self, connection):
        Author._connection = connection
        Author.createTable(ifNotExists=True)   


def createAuthorTable(connection):
    AuthorTable(connection)
    
    
    
createAuthorTable(connectionForURI('mysql://markus:eagle@localhost/books'))

a1 = Author(firstName = "J.R.R.", lastName =
"Tolkien")

----
the reason for this is that I want a generic modul
about authors and I want to specify the connection
Object at runtime, for example when I want
to use PostgreSQL.

the code works but I would like to know
if it has any flaws I do not see.

the reason for my question is, that I am
preparing an article about Object Relational Mapping
in Python for a german magazine. and
the main focus will be on SQLObject with 2 or
3 simple Examples.
I really like SQLObject and maybe the article
helps to get more people interested in SQLObject.
and I do not want to have any serious errors
in my examples.

thanks

regards

Markus





















> > 


	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

[SQLObject] FloatCol

[Marcin W. <wo...@un...>]

Hi,
FloatCol uses FLOAT column type for every datebase.
In Postgresql FLOAT mean double precision, I think the same in SQLite,
but in MySQL FLOAT is single precision. I think it would be better
to have double precision in every DB.
Patch below works for me.
Marcin


Index: col.py
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- col.py      (revision 210)
+++ col.py      (working copy)
@@ -401,6 +401,9 @@
     def _sqlType(self):
         return 'FLOAT'

+    def _mysqlType(self):
+        return "DOUBLE PRECISION"
+
 class FloatCol(Col):
     baseClass =3D SOFloatCol

Re: [SQLObject] Checking if a table exists ?

[Markus J. <mar...@ya...>]

thanks.this is what I was looking for.

regards

markus

 --- Ian Bicking <ia...@co...> schrieb: 
> paul kölle wrote:
> >> now I want to check everytime I start my programm
> >> if the table already exists and if not it should
> >> be created.
> > 
> > Author.createTable(ifNotExists=True)
> 
> Besides this you can also do
> __connection__.tableExists('author').  And 
> you could try something like:
> 
> if __connection__.tableExists('author'):
>      class DBAuthor(SQLObject):
>          _table = 'author'
>          _fromDatabase = True
> 
> And then you could compare DBAuthor._columns with
> Author._columns, to 
> make sure the schema was up-to-date.  From there you
> might just signal 
> an error if not, or you could try to do something
> more sophisticated. 
> But be warned that this introspection is getting
> into undocumented 
> portions of SQLObject, that might change in the
> future.
> 
> -- 
> Ian Bicking  /  ia...@co...  /
> http://blog.ianbicking.org
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE.
> Be one of 170
> Project Admins to receive an Apple iPod Mini FREE
> for your judgement on
> who ports your project to Linux PPC the best.
> Sponsored by IBM.
> Deadline: Sept. 24. Go here:
> http://sf.net/ppc_contest.php
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
>
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>  


	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [SQLObject] Checking if a table exists ?

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

paul kölle wrote:
>> now I want to check everytime I start my programm
>> if the table already exists and if not it should
>> be created.
> 
> Author.createTable(ifNotExists=True)

Besides this you can also do __connection__.tableExists('author').  And 
you could try something like:

if __connection__.tableExists('author'):
     class DBAuthor(SQLObject):
         _table = 'author'
         _fromDatabase = True

And then you could compare DBAuthor._columns with Author._columns, to 
make sure the schema was up-to-date.  From there you might just signal 
an error if not, or you could try to do something more sophisticated. 
But be warned that this introspection is getting into undocumented 
portions of SQLObject, that might change in the future.

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