Hello,

I have a quick question.

Using mysqlpp 2.1.1.

I want to pack a buffer into mediumtext column.

What type field should I specify when using

sql_create_N(...)

I want to create a row using sql_create and push that
into my table. The problem I'm having is that I'm
unsure on what row type field I need to specify.

I thought of using "string" type is this correct?

Help on this answer would be much appreciated.

Thanks,
Garyc


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

gary clark wrote:
Yes, string will work. It'll work for any textual field type, in fact.
Keep in mind, a lot of the SQL data types exist to allow you to trade
off total capacity against storage overhead. Unless your program has
need of similar in-memory tradeoffs, I wouldn't worry too much about
trying to find alternatives to string. In fact, if you had a memory-
bound program, I'd first look to changing store() queries to use()
queries wherever possible, rather than trying to squeeze bytes out of
SSQLSes.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Thanks Warren. I pushed the data into a mediumtext
column.
I then got the raw data using part of the example
in the user guide I think on page 21.
I can push out the raw data to stdout using fwrite.

Do you know how to convert this back to the original
data?

i.e L=76 , L being the raw data and 76 being the
equivalent? This might seem like a stupid question,
but is there a column type coverter to do this for me?

Again thanks,
Garyc

Is there a command to convert the raw data to decimal
--- Warren Young <mysqlpp (AT) etr-usa (DOT) com> wrote:


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

gary clark wrote:
I see...you are trying to pack smaller data items into a string. Okay,
understand, this is generally bad style. If you need a 1-byte column,
you should usually create a 1-byte column. If you have a variable
number of values, you just need another table, keyed to the first.

Just as an example, consider a business that has a Customer table, but
they decide that customers need multiple addresses. Instead of just
adding more address columns or trying to pack multiple addresses into
the existing structure, they correctly create the CustomerAddress table,
keyed on the ID column from the Customer table. This lets them have as
many addresses as they need, without trickery.

If you can't normalize the data this way for some reason, give Chris
Frey's packarray patch a look. It's in the mailing list archives. It's
mainly waiting for a little user love before it can be included in the
library.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Again Thanks Warren. I agree with you totally on
creating different tables. However the architect here
is well....stupid.
Hence I'm forced to use Chris Freys packarray a browse
and hopefully understand what is going.

Cheers,
Garyc
--- Warren Young <mysqlpp (AT) etr-usa (DOT) com> wrote:


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

gary clark wrote:
If it works out for you, please report about it to the list. If we can
get outside users for this patch, that will either generate new work
items or a general consensus that it belongs in the library as-is.
Either way, the documentation issue will get fixed if this happens
enough times.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw