Hey Koen,
2011/2/9 Koen Deforche <[email protected]>
> Hey Dmitriy,
>
> 2011/2/8 Dmitriy Igrishin <[email protected]>:
> > Hey all,
> >
> > Please note, that BLOB and bytea are different concepts in PostgreSQL:
> >
> > Large object (BLOB) - is a special structure which provides stream-style
> > access
> > to data.
>
> I guess this corresponds to this feature request:
> http://redmine.emweb.be/issues/700
>
Indeed, but please note, that any operation on large object (LOB) must be
inside transaction. So, I guess that specialized std::iostream must
encapsulate connection object and OID of LOB and open a transaction
in the constructor and close it in the destuctor ("resource acquisition is
initialization" technique).
>
> >
> > bytea - is a data type for storing binary strings.
> >
> > To process data of bytea type you need to retrieve the whole object
> > from the database into a memory. Next, you may use WMemoryResource
> > or save retrieved data to the file and use WFileResource.
> >
> > If you want to avoid working with whole objects (to avoid memory
> overheads)
> > you may want to use BLOB. To do this you need to extend WResource.
> >
> > Btw, I think it is reasonable to add WStreamResource into Wt -- the same
> as
> > WFileResource but for working with std::istream. I consider it useful.
> > Koen, how do you think ?
>
> I believe something like this is a good idea, but for a resource there
> is never a guarantee that there is only one reader at a given time
> (e.g. if you link the same resource from multiple images, or, for a
> static resource, or, if the browser simply decides to fetch it twice).
> This relates to the behaviour of HTTP 'GET' which is supposed to be
> idempotent.
>
> So, a WStreamResource would need to be able to seek into the given
> std::istream (corresponding to the current reading position of
> different readers). It is not entirely clear to me if istream's
> generally support this? e.g. I cannot imagine you can do it on
> std::cin ?
>
Yes, of course, std::istream should not be shared between threads.
It must be constructed locally inside handleRequest(). In case of LOBs,
each call of handleRequest() will get a connection (probably from pool),
construct LobStream then will perform the same algorithm as in
current WFileResource.
>
> In any case, I believe it diserves a feature request and perhaps
> WFileResource could be refactored to be a specializiatino of a
> WStreamResource.
>
So, maybe we need to add WStreamResource with a useful protected
method (e.g. doHandleRequest()) which operates with given std::istream
and called from handleRequest() (just generalization of current
WFileResource::handleRequest()) ?
Because the algorithm is common.
> Regards,
> koen
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> witty-interest mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
--
// Dmitriy.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
