Re: Problems with timestamp

#1

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

in <mysql++/sql_types.h> there are such lines
...
typedef Time sql_timestamp;
...

I guess it _really_ incorrect, it should be at least
...
typedef DateTime sql_timestamp;
...

That is just historical. We can't change it without a risk of breaking
existing code. But, I have placed your proposed fix on the v3.0 section
of the Wishlist. That would be the earliest point we could contemplate
changing it.

Quote:

And what about timestamp which would work as time_t?

I'm not sure what you're asking for here. My best guess is that you
want to be able to convert time_t to mysqlpp:

ateTime, and use that to
fill out a MySQL TIMESTAMP column? That's already on the Wishlist for v2.2.

Quote:

Again about SSQLS and static members. I've made a version of custom.pl - which
lives without static members, it creates custom_no_static.h and
custom_no_static-macros.h files. I guess it may be useful.

You shouldn't need that any more with the most recent two versions of
MySQL++. Do they not solve the problem for you?

Quote:

PPS How I can include patch?

Just attach it to the email message. If you are concerned that the
patch will not go through, you can send it to me via the bug tracker on
the MySQL++ project page at Gna!:

https://gna.org/projects/mysqlpp/

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

#2

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

hm... Can you give me a example of using sql_timestamp?

No. It's a mistake, but that doesn't mean I can go yanking features out
of the library at will.

Quote:

Again about SSQLS and static members. I've made a version of custom.pl -
which lives without static members, it creates custom_no_static.h and
custom_no_static-macros.h files. I guess it may be useful.
You shouldn't need that any more with the most recent two versions of
MySQL++. Do they not solve the problem for you?

Is it in SVN? I'll try it

I'm talking about version 2.1.0 where the fix was created, and version
2.1.1 where a fix was applied to it for Visual Studio 2003. The only
reason it wouldn't work for you is if you're using a compiler where the
feature cannot work.

Search custom.pl for MYSQLPP_NO_STATIC, or see the way this feature is
tested in examples/util.cpp.

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

#3

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

Search custom.pl for MYSQLPP_NO_STATIC, or see the way this feature is
tested in examples/util.cpp.

I guess, in such case I can't use field_list() function? Beside, field_list()
use names[], but in my patch there are no names[] at all.

I think you misunderstand the feature. You #include custom.h normally
within one module, and #define MYSQLPP_NO_STATIC before including it
again in other modules. This ensures that the static members are
defined only once, thus avoiding the problems of multiply defined static
data members.

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

#4

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

Why we can't just drop away static names[] ( and table)?

How would SSQLS build queries without a table of the field names?

Quote:

The only advantage IMHO is that we can change names[](table) on the
fly.

Every single table in my own use of MySQL++ has a different name than
the corresponding SSQLS. I am unwilling to give up that feature.

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

#5

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

÷ ÓÏÏÂÝÅÎÉÉ ÏÔ 17 ÏËÔÑÂÒÑ 2006 16:04 Warren Young ÎÁÐÉÓÁÌ(a):
ëÏÒÏÌÅ× éÌØÑ wrote:
Why we can't just drop away static names[] ( and table)?
How would SSQLS build queries without a table of the field names?

like this:

template <class Manip> std:

stream& operator << (std:

stream& s, const
DB_AdvBase_field_list<Manip>& obj) {
s << obj.manip << "user_id" << obj.delem;
s << obj.manip << "position" << obj.delem;
s << obj.manip << "ts" << obj.delem;
s << obj.manip << "pads";
return s;
}

IMHO in such way we don't need names[] at all.

Well, as a static example, that's interesting, but I'm not going to
rebuild custom.pl to implement it. If I were to spend a lot of time on
reworking SSQLS it would be to completely replace it with a different
mechanism. The current macro-based mechanism is hard to understand and
manipulate, so when we do run into problems, they tend not to get addressed.

This topic's come up before. I proposed defining the structures in XML
or some other such language and create a preprocessor that translates
that into header files defining the structures. This would be similar
to the way things like IDL work in CORBA and COM. The idea fizzled
because the driving force behind it at that time was Borland C++
incompatibility, but that problem's taken care of itself, leaving my
solution unnecessary.

You're welcome to tackle it, if you like.

Quote:

The only advantage IMHO is that we can change names[](table) on the
fly.
Every single table in my own use of MySQL++ has a different name than
the corresponding SSQLS. I am unwilling to give up that feature.

Explain please.

I mean that I will define an SSQLS called something like
SQL_MyTableName, where the actual MySQL table name is something else,
like my_table_name. There are several reasons I do this, but it's not
important to argue them here. The important point is, I and others
depend on being able to have C++ structure names that are different from
the corresponding SQL table names, yet still bind them together via SSQLS.

Quote:

In such case IMHO it's possible to declare "TableName" in other way.
#define TABLE_NAME "TableName"
Q << "SELECT " << obj.field_list() << " FROM " << TABLE_NAME;

Why would I want to do that? The whole point of SSQLS is to reduce the
amount of SQL statements in my C++ code. This is a regression.

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

#6

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

I proposed defining the structures in XML
or some other such language and create a preprocessor that translates
that into header files defining the structures.

Unfortunately in closest period I'm enough
busy, but in next months I'll try take it.

That's fine, I couldn't accept it before v3.0 anyway.

Quote:

are there any concrete ideas? Just to move in correct way.

Start with the file format. Something like this:

<?xml blah blah blah>
<ssqls class="MyStructureName" table="MyTableName">
<field type="mediumint" name="myFieldName" null="1" />
<field type="datetime" name="myOtherFieldName" />
</ssqls>

The file name should use a unique extension (.ssqls ?) so you can write
build rules. For example, in Makefile syntax:

..ssqls.h:
ssqlsgen $@

....takes mytables.ssqls and creates mytables.h. (Maybe creates
mytables.cpp, too, but I'm not certain about that. It might be better
if everything remained inline.)

For this to be valuable, the mechanism needs to:

1. Write clear, well-formatted C++ code

2. Create classes that are easy to subclass without problems. This
means that there should be as little public and protected methods and
data as possible.

3. Cope with different type systems. Notice above that I'm using SQL
type names. It should be smart enough to translate those into the
proper MySQL++ type names. Likewise, if I put in, say, time_t, it
should be able to figure out the right thing to do there, too.

4. Work with the Null<> template. Notice this in the first field
definition.

5. SSQLS structures should derive from a common base class. This let
you put some useful common code in the MySQL++ library itself, but more
importantly, it would let you make methods like Query::insert() into
regular methods instead of templates.

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

#7

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

That's fine, I couldn't accept it before v3.0 anyway.
Possibly, we can try to make an unstable branch. And for example 2.2, 2.4, etc
will be stable, and 2.3, 2.5, etc will be unstable. In that case, it would be
possible to include new features not in 3.0, but earlier.

It has nothing to do with stability. If it helps you to think about it
more clearly, the svn repo is our "unstable branch".

v3.0 is for those things that will break end user code, as your proposed
changes will.

Quote:

3. Cope with different type systems. Notice above that I'm using SQL
type names. It should be smart enough to translate those into the
proper MySQL++ type names. Likewise, if I put in, say, time_t, it
should be able to figure out the right thing to do there, too.

Give a more detailed description, please.

I mean that if the XML file contains "sql_timestamp", "TIMESTAMP" or
"time_t", the parser should be smart enough to realize that these are
all effectively the same type. I don't want the type to be copied
literally into the header file; I want it to be translated intelligently.

Quote:

5. SSQLS structures should derive from a common base class. This let
you put some useful common code in the MySQL++ library itself, but more
importantly, it would let you make methods like Query::insert() into
regular methods instead of templates.

Give a more detailed description (example), please.

What else needs to be explained? It would be useful if all SSQLSes
derived from a common base class that lives in the MySQL++ library.
There's nothing more complicated than that to it.

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

#8

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

5. SSQLS structures should derive from a common base class. This let
you put some useful common code in the MySQL++ library itself, but more
importantly, it would let you make methods like Query::insert() into
regular methods instead of templates.
Give a more detailed description (example), please.
What else needs to be explained? It would be useful if all SSQLSes
derived from a common base class that lives in the MySQL++ library.
There's nothing more complicated than that to it.

I mean "what do you think about interface of that common base class"

It doesn't have to have _any_ methods to be useful. Just the ability to
pass it to Query::insert() and similar methods will make it useful
enough. If you want to get ideas for other methods it might have, try
running some v2.1 SSQLSes through doc/ssqls-pretty

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

#9

ëÏÒÏÌÅ× éÌØÑ wrote:

Quote:

Explain please, why "It doesn't have to have _any_ methods to be useful"?

Sigh...I think we must have a language barrier here. The statement is
not important enough to argue about. If you don't understand my
meaning, don't worry about it.

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

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Re: Problems with timestamp

mailing.database.mysql-plusplus mailing.database.mysql-plusplus

Re: Problems with timestamp - 10-16-2006 , 07:38 PM

Re: Problems with timestamp - 10-17-2006 , 03:48 AM

Re: Problems with timestamp - 10-17-2006 , 05:14 AM

Re: Problems with timestamp - 10-17-2006 , 07:08 AM

Re: Problems with timestamp - 10-18-2006 , 07:21 AM

Re: Problems with timestamp - 10-18-2006 , 01:36 PM

Re: Problems with timestamp - 10-24-2006 , 04:41 PM

Re: Problems with timestamp - 10-25-2006 , 08:15 AM

Re: Problems with timestamp - 11-20-2006 , 01:32 PM