I understand your question if you are getting different data from the server in the two database accesses. But if you are loading the exact same data twice for a page load, you should try to eliminate that redundancy instead of finding a plan to perform the redundancy in the best way.
If it's the identical data twice, then why not render it into the page when you are rendering the HTML... you can render hidden fields, CDATA sections, regions of javascript containing any data structure you need, etc. It's a confusing question because if it's two different DB requests then you wouldn't be inquiring about caching for this purpose, but if it's two identical DB requests I suspect you already would have realized that the data could easily be encoded in the original page render. On Oct 28, 4:22 pm, Alvaro Reinoso <alvrein...@gmail.com> wrote: > Hey guys, > > I have a doubt. I need to get the data from the sever twice every time > when I load a page, one to render the HTML and another one to get the > data for client side (javascript). > > So I don't know exactly what it's the best way and fastest. I was > trying to implement a session object and store the data once using > joinedload loading technique. When the data is in the client side, to > kill the session object. > > Another one it's to call the database twice. > > I don't know which one is faster and better because I don't know if > the database or server stores the first call in memory. If so it's not > like to call the database twice, right? > > And if the second choice is better which loading technique > (joinedload, eagerload or subqueryload) is better to use. > > Every call could be a bunch of data. > > Any help could be really useful. > > Thanks in advance! -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
