Yes. that is why we do not have it yet. This is the problem to be
solved
On Apr 15, 3:53 am, AchipA <attila.cs...@gmail.com> wrote:
> Careful with sessions in ram. Your app can go schizophrenic if you
> have, say, multiple wsgi processes. Your user would appear to have one
> session when going to one of the processes, and another when ending up
> on the other wsgi process. The same caveat exists with cache.ram
>
> With the disk-on-app your best bet is fuse anyway, so you can change
> the filesystem, but the changes are stored in memory.
>
> On Apr 14, 4:28 am, Iceberg <iceb...@21cn.com> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
