Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#86 BLOB and CLOB

Release_1.3.6
closed
None
5
2012-09-14
2008-11-12
Alex Fabijanic
No

I'm doing some (re)design thinking for the next release and I'd like to do following:

  • introduce LOB<T>
  • typedef LOB<unsigned char=""> BLOB
  • CLOB : public LOB<char>

CLOB would be UTF-8 and this redesign would open the road for extensions to other encodings. This modification will break code that constructs BLOB from from or transparently exchanges data with std::string, but that would be needed for such cases is to use CLOB instead.

Any objections? Suggestions? Comments?

Discussion

  • Definitely a good idea! It is better to define an appropriate CLOB than forcing some encoding at some point of application-poco-odbc-database chain. Eg. LOB<wchar_t> perfect for utf-16, fits in string<wchar_t> and everybody sees what he gets.

    Be careful when you decide the meaning of size() since this way it would return the number of elements (length of the string) instead of the allocated space in bytes!

     
  • Alex Fabijanic
    Alex Fabijanic
    2008-11-15

    Eg. LOB<wchar_t> perfect for utf-16, fits in string<wchar_t> and
    everybody sees what he gets.

    That is not always the case because wchar_t is not guaranteed to be 16-bit.

     
  • OK, it was just an example that the enclosed type can be seen through the source which is a good idea!
    (AFAIK, wchar_t is 16 bit or more and on Linux it is 32 bit wide)

    Obviously, to be transparent with the database field an appropriate type must be used!

     
  • Alex Fabijanic
    Alex Fabijanic
    2008-11-24

    Done in SVN, rev. 991. Closing.