Hello Arnon. I just made a quick search of your posts on the other groups on groups.google.com..
On many (almost all) groups that you have made posts, you run into arguments with longtime members/contributors that have put down huge amount of time in the projects. You say yourself in many posts, that you are inexperienced in the subject that are being discussed? Then, perhaps it's good to take a more humble approach when addressing your questions/statements? I can only speak for myself, that I should at least pick that approach if I had a question to the community.. Don't misunderstand me, It's always good with new ideas and fresh insights.. But when meeting massive resistance in a community about an idea that doesn't seem to get any traction, then perhaps that idea shouldn't be forced with endless arguments just to "win"? Sorry for the OT, and this is just a friendly hint from an old news user :) -- Kind Regards Jufsa Lagom On Thursday, January 16, 2014 11:57:05 PM UTC+1, Arnon Marcus wrote: > > Derek: Are you being sarcastic and mean? > > > >> cache doesn't cache only resultsets, hence pickle is the only possible >> choice. >> >> > > Well, not if you only need flat and basic objects - there the benefit of > pickle is mute and it's overhead is obvious - take a look at this project: > https://redis-collections.readthedocs.org/en/latest/ > > >> It's cool. Actually, I started developing something like that using DAL >> callbacks, but as soon as multiple tables are involved with FK and such, it >> starts to loose "speed". Also, your whole app needs to be coded a-la >> "ActiveRecord", i.e. fetch only by PK. >> > > Hmmm... Haven't thought of that... Well, you can't search/query for > specific records by their hashed-values, but that's not the use-case I was > thinking about - I am not suggesting "replacing" the dal... Plus, that > restriction would also exist when using pickles for such a use-case... > What I had in mind is simpler than that - just have a bunch of simple > queries that you would do in your cache.ram anyways, and instead have their > "raw" result-set (before being parsed into "rows" objects) and cached as-is > (almost...) - that would be faster to load-in the cache than into > cache.ram, and also faster for retrieval. > > >> BTW, I'm not properly sure that fetching 100 records with 100 calls to >> redis vs pulling a single time a pickle of 1000 records and discarding what >> you don't need is faster. >> > > Hmmm... I don't know, redis is famous for crunching somewhere in the order > of 500K requests per-second - have you tested it? > > >> BTW2: ORM are already there: redisco and redis-lympid >> > > 10x, I'll take a look - though I think an ORM would defeat the purpose (in > terms of of speed) and would be overkill... > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
