------=_Part_10999_24556771.1150872680129
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have a few large classes which I wish to save to a MySQL table. Currently
I am saving them to flat files using override>> and override<< with streams.

By large I mean 47+ variables/fields.

I'm trying to determine the best way to do this using MySQL++. I've been
looking at SSQLS but think it would be a real pain to maintain.

I really didn't see an override for >> or << in the documentation, but I may
have just missed is. Is there an override that will let me do something
like:

con.something() << Field1 << field2 << field3 << field4;
con.insert(); // or something

con.something() >> Field1 >> field2 >> field3 >> field;
etc?

------=_Part_10999_24556771.1150872680129--

There are << >> overloads for the 'Query' object. You can do =
something like

Query query =3D con.query();
if (query) {
query << "INSERT INTO " << <table> "(" << <Field1> "," << <Field2> << =
"," ... ")" << "VALUES (" << <value1> << "," << <value2> << "," ... =
");";
ResNSel result =3D query.execute();
if (result)
long rows_affected =3D result.rows;
}

Of course, it's all relative. The above SQL string created with 40+ =
field-value pairs could also be hard to maintain.

HTH...steve---


Steven J Orton
Software Engineer
Northrop Grumman Mission Systems
Middletown, RI 02842




-----Original Message-----
From: Jim Langston [mailto:serpardum (AT) gmail (DOT) com]
Sent: Wed 6/21/2006 2:51 AM
To: MySql++
Subject: Large class to table
=20
I have a few large classes which I wish to save to a MySQL table. =
Currently
I am saving them to flat files using override>> and override<< with =
streams.

By large I mean 47+ variables/fields.

I'm trying to determine the best way to do this using MySQL++. I've =
been
looking at SSQLS but think it would be a real pain to maintain.

I really didn't see an override for >> or << in the documentation, but I =
may
have just missed is. Is there an override that will let me do something
like:

con.something() << Field1 << field2 << field3 << field4;
con.insert(); // or something

con.something() >> Field1 >> field2 >> field3 >> field;
etc?


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

Jim Langston wrote:
Read up on template queries in the user manual. Then keep reading the
user manual, because you might just discover other interesting things.

You might also consider subclassing from SSQLSes, so you can insert your
more complicated classes directly. Unless you run into some kind of
overload conflict, this should work. The main consequence of this is
that it makes the data members public, which is a no-no in some coding
shops.

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

Warren Young wrote:
One other thing: you'll have to change the value at the top of
querydef.pl and re-run the script, since the default limit is 25 fields.

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

------=_Part_18674_21487667.1151484918299
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/21/06, Warren Young <mysqlpp (AT) etr-usa (DOT) com> wrote:

I've been giving this some thought, and have come up with a way to design a
class that will work in the way I want. I see no reason, other than a few
more calls, that a class couldn't build the SQL string itself. The biggest
part, of course, would be the field names, but that already exists in the
INFORMATION_SCHEMA_COLUMNS table and even seems to be exposed in MySQL++ in
the query.store() return.

My main question then becomes, why hasn't anyone done this yet, or has
someone? I see this to be very benifitial, where I would be able to do
something like (and this would not be exactly the way it woudl be, more like
pseudo code):

Connection con(use_exceptions);
if ( ! connect_to_db( argc, argv, con ))
{
return 1;
}

TableSet UserTable( con, "abyssal.user" );
// This would actually build the field information and store it in a
TableSet class.

UserTable.insert() << MyString << MyFloat << MyInt << MyOtherInt << MyBool;

Query query = con.query();
query << UserTable.insertquery();

// rest standard MySQL++ stuff

The main disadvantage I see is the time required to build the table
information for the table. But this should only have to be done once for
each table, and be reusable over and over for many queries, inserts,
changes, etc... in the particular table.

Does anyone think this would be a Good Thing or a Bad Thing? If people
think it would be a Good Thing (and I personally do) then I will go and
write it. It is something I really want that makes queries a little more
dynamic IMO.

------=_Part_18674_21487667.1151484918299--

Jim Langston wrote:
It sounds like you're in the middle of reinventing SSQLS, so the answer
is, someone already has done this.

The only difference between this and SSQLS is that SSQLS is a statically
typed system, fixed at compile time, and this alternative is dynamically
typed. But since SQL is statically typed and is not object oriented in
any meaningful way, I'm not sure there's any real advantage to going
with dynamic typing here. It's a matter of preference, not one of being
able to do something one way that you cannot do at all any other way.

Obviously I'm rather dismissive of it, but don't consider this a
complete shoot-down. I don't have much use for template queries,
either, but I'm not going to go and remove them from the library.

If you build this and the implementation seems to be reasonable, there's
a fair chance I'll add it to the library. The only caution I offer to
you is that if you want it to appear before v3.0, it can't break the
library's ABI. That means you cannot change the signature of any
existing functions, and you can't change the inheritance hierarchy;
there are probably other limits I'm forgetting now. Basically, if you
can't do it by just adding new member functions and new classes, it'll
break the ABI, so it'll have to wait until v3.0.

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