Read it, Thanks Scott. I have one question there. Under the third enhancement how that will affect the connection pooling?
When the developer is allowed to change a preconfigured connection's (from a set of connections in the pool) schema and once he done with it the connection will return to the pool with other connections pointing to another schema. The developer must take the responsibility to make sure they are used properly? . Is this for an Application using several schemas (I never worked with such)?. This is just a thought I had after reading this.
Good question. It was 9pm when I had at that technical session so I was pretty tired (full day of classes). My guess would be it would be up to vendors who build the servers to ensure some amount of security in setSchema(). For example, in a connection pool environment, the command may throw a security exception.
Kavita Tipnis
Ranch Hand
Joined: Sep 21, 2008
Posts: 177
posted
0
Scott,
Under the 4th enhancement why a DATETIME datatype is not considered?
Do you mean Java Timestamp? From what I gleaned, the time zone issues aren't going to be solved in 4.1, one of the reasons cited being they need to implement a design solution that is backwards compatible with existing JDBC code. We'll have to see what they come up with down the road.
Kavita Tipnis
Ranch Hand
Joined: Sep 21, 2008
Posts: 177
posted
0
My naive look comparing the MySQL date/time datetime and timestamp datatypes to map with one of the data types in java.sql package brought that question.
In the Statement interface there is an "executeUpdate(String sql, int autoGeneratedKeys)" method which allows you to ask for the keys generated by an INSERT statement. But the PreparedStatement interface doesn't have an "executeUpdate(int autoGeneratedKeys)" method corresponding to that. It's a design defect so all the people who reported it as a bug were brushed off with the excuse that they should have filed an RFE instead.
0
