This keeps pulling at my attention, so forgive me for thinking out loud a
bit more...
On Fri, Mar 13, 2009 at 6:43 PM, Yarko Tymciurak <yark...@gmail.com> wrote:
*snip*
>
>> 2) Thanks for the ipython suggestion and the SQLDB._instances
>> explanation.
>> What I find obscure is the use of SQLBD._instances by itself.
>> SQLDB is a class and yes, it has an attribute named _instances, so
>> far so good.
>
>
Let me try to take the case of language clarity one more step...
The Problem area web2py is dealing with here is NOT in making a database, or
SQLDB actually, and this is the source of confusion.
The real situation is that the the 'db' in web2py is a connection from a
pool of connections. From the point of view of the web2pyserver, there is
a connection pool. The application is only one of the threads using some
number of connections. At any given point, a request fires up
an application thread, and that request serves that client session, and
establishes one (for the sake of discussion) connection to the db server on
behalf of the web client - on behalf of this client session, this client
request.
So let's call SQLDB class SQLDB_CONNECTION for this discussion.
so here's a verbose version of what we have:
db_connection=SQLDB_CONNECTION()
Now, do we create a database? With the exception of sqlite, no. The
database and connection method must be pre-established - before the
application makes it's first run. So, we do not really have
db=SQLDB()
although the notation is short, and serves well enough for the way
application writers think. It does, however, mask something important - you
are not making a db object, nor db tables - you are connecting to a db and
talking through an interface to the schema, and web2py is managing the
connection pools for you.
That interface has a couple of interesting characteristics: It must match
the table definition. It need not include all of the table definition
(which is evidence, after all, that it is just an interface - a portal to
the data tables, a descriptor).
Thought the portal to your data does not need to include all the fields, it
must match what's at the db server end. What happens when your app needs to
create new tables? change size of fields? change type of fields? add or
remove fields?
Well, if you needed to go to the database server and update the table
manually (and that's the way it is in many web applications!), then it would
be more work, and probably more down time for your site.
Now let's talk about migrations.
What is a migration, really? One way to think of it is a change in state
of the connection: it is an agreement to switch, if you will, between the
data channel of the connection to the control channel. From CRUD of rows
to modification of the schema. Web2py does this thru the connection by
keeping track of it's understanding of the schema, and - whenever it sees a
change in the schema, sending out scema-change requests to the db server.
So, we have an interface to the table schema, and a way to keep it in sync
-- through the connection.
A table may have many connections to it at any one time. That's why web2py
server needs to be able to keep track of them thru SQLDB_CONNECTIONS (which
I've renamed for this discussion).
So - to get back to the obscurity which DenisL pointed out - the use of the
SQLDB._instances, which I've tried to have the name better say what it is
doing:
SQLDB_CONNECTIONS._by_threads and
db_connection._by_threads
I may be changing the name now and then, but each is probably as good to
read as another; to tell the truth, I like the shorter, existing names
better for most day-to-day uses, with the exception of _instance -- I firmly
believe _by_threads is a better name.
That's all I've got for now on this.
- Yarko
> Ok - let's call it by what it is: SQLDB._open_by_thread just to make
> reading this easier...
>
>
>> Defined databases are instances of SQLDB and I would understand the
>> use of dbA._open_by_thread but SQLDB._open_by_thread?.
>
>
> again, language helps here: rewriting your statement shows how much sense
> this makes in each case.
>
> Think this way: db_connection ==> open_by ==> [pid, ...]
> and SQLDB_sessions ==> open_by ==> [pid, ...], each with ==> db_instances
> connected to (an instance in a session)
>
> Make more sense?
>
>
> 3) In the meantime to find the defined databases I came up with
>> something like this:
>>
>> DBs={}
>> DBtype=type(SQLDB())
>> for n in globals():
>> if type(globals()[n])==DBtype:
>> DBs[n]=globals()[n]
>>
>> I think I needed something like this a while back...
>
>
> Ok... but you get the same for currently open session, and you get that
> from any process... which can see what other sessions are open...
>
> So, not sure what you're getting out of this that you don't from the
> former...
>
> Regards,
> Yarko
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
