request:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

session:

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

response:

==========================================================================

From http://groups.google.com/group/web2py/browse_thread/thread/3654863ae1de26a1

, I would define tables

as usual only to get an SQL error saying the table exists.

 

 

From: mdipierro < mdipie...@cs.depaul.edu >

Date: Mon, 4 May 2009 07:23:39 -0700 (PDT)

Local: Mon, May 4 2009 10:23 am

Subject: Re: Table already exists problem [again]

 

This is complex. Currently the way to avoid the problem is to name

the .table files via

 

db.define_table('something',.. ..,migrate='something.table')

 

 

using "IF EXISTS" would only solve this problem to create others.

 

 

Massimo

 

 

From: mdipierro < mdipie...@cs.depaul.edu >

Date: Mon, 4 May 2009 16:29:46 -0700 (PDT)

Local: Mon, May 4 2009 7:29 pm

Subject: Re: Table already exists problem [again]

 

web2py, for now, does not have the ability to query the db about which

tables are in there are stores metadata about that in .table files.

 

If we enable IF_NOT_EXISTS it means web2py is ignoring metadata

from .table file (else IF_NOT_EXISTS) would not be needed at all.

 

 

If the table exists but differs from the current model, web2py will

not be able to detect it, will not be able to migrate, and it will

just not work.

 

 

This will make apps harder to debug and data more difficult to

recover.

 

 

Right now if the table exists and you do not want migrations just set

migrate=False.

You cannot at the same time ignore .table files and have migrations.

 

 

If you learn how to manipulate .table files (by giving them names

instead of using the default names) you can fix every problem.

 

 

From: mdipierro < mdipie...@cs.depaul.edu >

Date: Tue, 5 May 2009 07:25:43 -0700 (PDT)

Local: Tues, May 5 2009 10:25 am

Subject: Re: Table already exists problem [again]

 

I am not sure what you mean by "in a way that it survives framework

updates".

 

The only problems I can see would arise if:

- You delete databases/*.table but the database is still there

(updates do not cause this). Bad luck. One should not delete files, or

at least make a backup.

- Your databases/*.table are still there but you change name or login/

password for the actual database. This is not a problem. You only need

to rename the old *.table files. By default the file names are md5

hashes of the dburi string. 

Notice that you can do

 

 

auth.define_table(migrate= False)

 

Massimo

 

  The current system does not limit

that. It only limits the fact that one app should do migrations. If

more than one app may do migrations just symlink the database folder.

 

Massimo

TW...

 

I do not think the current system is perfect. Ideally web2py should

query the database for the current table stucture instead of using

local .table files. .table files exist because

- I do not know an alternative

- because it is faster to look this up locally than query the database

 

 Massimo

  

 

NOTE by Dave Lypka:

When I did this this on remote existing SQL Server database tables, web2py worked fine.

 

try:

    from gluon.contrib.gql import *         # if running on Google App Engine

except:

    db=SQLDB('sqlite://storage.db')         # if not, use SQLite or other DB - Used by T2

    dbmssql = SQLDB('mssql://dlypka:none@localhost/TMoMilestones')

 

dbmssql.define_table('TMoProjectIdView',

                dbmssql.Field('strProjectType','string'),

                dbmssql.Field('strProjectName','string'),

                dbmssql.Field('strProjectDescription','string'),

                dbmssql.Field('dtCreated','datetime'),

                dbmssql.Field('dtLastupdate','datetime'),

                migrate=False)

 

==========================================================================

 

 

From: mdipierro < mdipie...@cs.depaul.edu >

Date: Wed, 6 May 2009 22:26:16 -0700 (PDT)

Local: Thurs, May 7 2009 1:26 am

Subject: Re: Stream a blob

 

On May 6, 10:05 pm, rbp < richar...@gmail.com > wrote: 

> hello, 

> I just noticed that web2py has an easy way to stream data - that's

> fantastic!

> Currently I upload and download data without streaming which is really

> tough on my web2py server. 

> All the examples I've seen are for streaming a file on the file

> system. Is it possible to stream a blob fieldtype without loading it

> all into memory at once? 

No because web2py base64 encodes blobs.

 

> Also, how can I manually stream an upload? I am trying to save the

> posted data with a request without the server having to load it all

> into memory at once. 

If you use SQLField('file','upload') it ill by default stream in

upload and download.

If you use SQLField ('file','upload',uploadfield=' the_blob_field') then it must be read in

memory at once in order to communicate with the DB.

 

Massimo

 

===================================================================