Thanks Yarko's insight on the topic of db performance domain.
As to me, I brought up the issue only because I want to store sessions
in RAM. In many cases sessions are not needed to be persistent on
disk. Ram means maintenance free here, that way there is no need to
delete old session files anymore. By the way, I personally plan to
develop an desktop app which will be run on a CD, so the disk is not
writable at all. Mmm, still a long way to reach that goal, but ram-
based session will be the first milestone.
So, if only sessions can be put in ram, that is ok for me. If an
entire db can be fit into ram, that is better because session can be
stored in this ram db by session.connect(...,db).
On Apr14, 2:17am, Yarko Tymciurak <yark...@gmail.com> wrote:
> 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
