The issue I raised coincides with what iceberg has described. I also agree with Yarko on the data persistence as a backend. But db in ram would be amazing as you can seamlessly use all DAL features ! Hopefully if we can get more traction on this feature.
On Apr 14, 9:31 am, Yarko Tymciurak <[email protected]> wrote: > Thanks Iceberg - this makes some sense... > > > > On Mon, Apr 13, 2009 at 11:28 PM, Iceberg <[email protected]> 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 <[email protected]> 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
