Hi all,
I´m new to the forum and this is my first post.
I´m trying Zeos and i´m very excited to see a JDBC-like interface set for Delphi. Congratulations for the work.
Comparing version 7 with version 6, i see it introduces a 'Prepare' method for the IZPreparedStatement interface.
I know you are probably aware of it, but, IMHO:
- interface changes should be avoided when possible
- you should keep ZDBC as close to JDBC as possible
- ZDBC (and JDBC) are mature and tested enough, and this interface change seems no usefull (at least for my eyes)
I´m wondering why should i need to 'Prepare' a 'Prepared' statement? Maybe i´m missing something obvious?
Regards,
Fabiano
[bug_fixed] IZPreparedStatement.Prepare reason
Moderators: gto, EgonHugeist, olehs
-
- Fresh Boarder
- Posts: 15
- Joined: 13.02.2009, 18:55
- Location: Americana/SP
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Hi,
If you look deeper into the matter you might seeThe former 'prepared' statements were just prepared/bound/executed/dropped at every execution.
What we wanted to implement now is a way to prepare a statement, keep it alive for multile bind/executes and let the user choose when it's dropped.
Was there a way to do this before?
Please let me now if something that worked before doesn't work anymore. There's no intention t break existing code, but I must admit, I'm not a zdbc programmer.
Mark
If you look deeper into the matter you might seeThe former 'prepared' statements were just prepared/bound/executed/dropped at every execution.
What we wanted to implement now is a way to prepare a statement, keep it alive for multile bind/executes and let the user choose when it's dropped.
Was there a way to do this before?
Indeed : LIKE. No reason to keep it like that. As it's not a Java implementation, so no reason to say 'mature and tested enough'a JDBC-like interface
Please let me now if something that worked before doesn't work anymore. There's no intention t break existing code, but I must admit, I'm not a zdbc programmer.
Mark
-
- Fresh Boarder
- Posts: 15
- Joined: 13.02.2009, 18:55
- Location: Americana/SP
Well, if you look at Zeos interfaces, they are actually an exact copy of JDBC interfaces in its essence. And, if i remember well, i read in zeos documentation that it you want to know ZDBC deeper, you should search JDBC api :-)
Despite that, JDBC/ZDBC are just interfaces. You can implement the drivers the way you want.
If you look deeper into the matter you might see it´s possible to program the driver to doesn´t drop the statement after execution, without the need to change the interface. You could drop the statement just when the statement instance is destroyed, what is done automatically when there are no more references to it. I think it´s clever than messing up the interface.
Zeos creator was very wise to start over a solid base as JDBC (and yes, mature and tested enough), and you should keep following this base strictly. In my humble opinion, this change was not thought deeply enough.
The fact that this change 'doesn´t break existing code' is not a reason to implement it. Based on this argument we should add all kind of crap that comes to mind to help one database or another, but we would left the JDBC essence behind, which is a simple and efficient abstraction to database access.
I´m not saying statement preparation is useless. I just think it could be implemented inside the drivers, transparently.
Regards,
Fabiano.
Despite that, JDBC/ZDBC are just interfaces. You can implement the drivers the way you want.
If you look deeper into the matter you might see it´s possible to program the driver to doesn´t drop the statement after execution, without the need to change the interface. You could drop the statement just when the statement instance is destroyed, what is done automatically when there are no more references to it. I think it´s clever than messing up the interface.
Zeos creator was very wise to start over a solid base as JDBC (and yes, mature and tested enough), and you should keep following this base strictly. In my humble opinion, this change was not thought deeply enough.
The fact that this change 'doesn´t break existing code' is not a reason to implement it. Based on this argument we should add all kind of crap that comes to mind to help one database or another, but we would left the JDBC essence behind, which is a simple and efficient abstraction to database access.
I´m not saying statement preparation is useless. I just think it could be implemented inside the drivers, transparently.
Regards,
Fabiano.
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Well Fabiano,
It has taken me more than a week to respond. Specially for this post I didn't logon all this time to avoid losing this message in my unread posts
Let me start by saying, I don't even know the jdbc API. So it's not so strange I broke the rules. If I remember well, I just added these dbc functions for making the code more transparant/'split up'. I imagine it might even be possible to just drop these functions from the interfaces and keeping them in the underlying Abstract Objects implementing the interfaces to have exactly the same results.
I have a question for you : could you fix the zdbc implementation keeping jdbc interface unchaged? Seems you've been doing some research. If your version passes the same test suite nothing will keep me from changing the stuff again.
Mark
It has taken me more than a week to respond. Specially for this post I didn't logon all this time to avoid losing this message in my unread posts
Let me start by saying, I don't even know the jdbc API. So it's not so strange I broke the rules. If I remember well, I just added these dbc functions for making the code more transparant/'split up'. I imagine it might even be possible to just drop these functions from the interfaces and keeping them in the underlying Abstract Objects implementing the interfaces to have exactly the same results.
I have a question for you : could you fix the zdbc implementation keeping jdbc interface unchaged? Seems you've been doing some research. If your version passes the same test suite nothing will keep me from changing the stuff again.
Mark
-
- Fresh Boarder
- Posts: 15
- Joined: 13.02.2009, 18:55
- Location: Americana/SP
Mark, excuse my delay also.
I was expecting to receive a e-mail notification when this topic had an answer, but i misconfigured my profile, and just now i saw your post. I had turned e-mail notifications on, so from now i pretend to be more responsive.
Yes, i could help in this task, and in other tasks also. Just provide me some documentation from where i should start (how do i run the tests, where should i get the code from, where should i send the changes, etc...)
Regards,
Fabiano
I was expecting to receive a e-mail notification when this topic had an answer, but i misconfigured my profile, and just now i saw your post. I had turned e-mail notifications on, so from now i pretend to be more responsive.
Yes, i could help in this task, and in other tasks also. Just provide me some documentation from where i should start (how do i run the tests, where should i get the code from, where should i send the changes, etc...)
Regards,
Fabiano