temporary tables as a performance issue seem reasonable...
Solving database storage performance in web2py seems the _wrong_ place to do
this.
Temporary tables (per-request) which help manage web2py's assumption that
everything is data-driven, that is so you can take advantage of forms, etc.
seems like a good use of ram-based / "virtual" tables for per-request
situations where you want to have the full web2py API at your disposal
(validations, forms, etc).
Temporary (ram-based) tables to address persistent data performance issues
should NOT be solved by web2py (if you find some _really compelling_ reason
that there is some exceptional case where this makes sense, by all means
present your case! but I don't see anything approaching that right now...)
Data-presistence performance issues (that is, back end issues) should be the
domain of, and solved by the backend. Some suggestions: Re-structure what
you are doing to avoid your specific situation (why are you creating _many_
temporary tables???); select a deb backend that supports temporary tables
or other performance concerns that are specific to those you are
experiencing (Oracle and T-SQL, Postgres at least support temporary tables).
IN this regard, it _might_ make sense to have DAL support a "as TEMPORARY"
option for table definiton (as a hint - if the backend supports it, it will
use it, otherwise you just get a "normal" table). I have no idea what the
various options and behaviors of temporary tables are, but this (at least)
would be in the right direction for web2py....
I'm really not (at this point) for this particular proposal - I would much
prefer to see thinking around something more like:
db.table_create('sometable', ......, migrate=Temporary) # ? or maybe a
separate keyword, but this _does_ seem like a kind of migration issue
More discussion please!
- Yarko
On Mon, Apr 13, 2009 at 11:50 AM, vihang <[email protected]> wrote:
>
> I like the proposal very much. Will be very useful. In the project I
> am working with, we need to create a lot of temporary tables. And
> memory seemed very good option.
>
> On Apr 13, 8:22 pm, Iceberg <[email protected]> wrote:
> > If you are talking about where to store those *.table files, how about
> > just store them inside a "system_table" in the db=SQLDB
> > ('sqlite:....')? In this way perhaps we don't need *.table
> > anymore.... but I might be wrong. :P
> >
> > On Apr14, 0:02am, mdipierro <[email protected]> wrote:
> >
> > > Here is a proposal
> >
> > > db=SQLDB('sqlite:memory:appname',cache=cache.ram)
> >
> > > Working on this but the problem is determining whether tables are
> > > there or need to be created.
> >
> > > Massimo
> >
> > > On Apr 13, 10:30 am, Iceberg <[email protected]> wrote:
> >
> > > > This is a topic with long history.
> http://groups.google.com/group/web2py/msg/df79e41f2298bef2
> >
> > > > Hopefully Massimo will eventually find a way to implement a ram based
> > > > db. :-)
> >
> > > > On Apr13, 10:44pm, vihang <[email protected]> wrote:
> >
> > > > > There maybe something wrong in my understanding, in which case
> please
> > > > > correct me, but db objects created using sqlite:memory: are not
> > > > > persistant. i.e. insert does not work? Is this is a bug ? If not,
> > > > > could someone tell me what it is suppose to do?
> >
> > > > > To replicate behavior, create new db object (db =
> SQLDB('sqlite....., )
> > > > > and define table. The database admin does not insert any rows, nor
> can
> > > > > any statements from controller.
> >
> > > > > Vihang
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
