[dba-issues] [Issue 55884] [dev] clean up resultset/ statement/metadata relationship in various SDB C drivers
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55884 --- Additional comments from [EMAIL PROTECTED] Mon Oct 17 00:16:16 -0700 2005 --- With respect to first solution: implExecuteQuery( String, XMetaData ) I am feeling this is not going to work. For a normal statement, the meta data is in the result set, remember? With respect to second solution: the Statement bass class could hold the meta data object and remember the statement it holds for That sounds like what a result set currently does... We won't win anything. I have not investigated anything seriously yet, so we are in the domain of feelings, intuition and impressions. But I am feeling the solution needs is much simpler and does not need such radical changes. It's either a matter of having the right constructors or to isolating cleanly the initialization of the meta data in some dedicated method, according to me. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 55884] [dev] clean up resultset/ statement/metadata relationship in various SDB C drivers
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=55884
--- Additional comments from [EMAIL PROTECTED] Thu Oct 13 23:35:21 -0700
2005 ---
well, this could be worked around by introducing something like
implExecuteQuery( String, XMetaData )
which is called from both Statement::executeQuery and
PreparedStatement::execute.
Alternatively, the Statement bass class could hold the meta data object, and
remember the statement it holds for. Then, every time a new result set is
created, for some given statement, it's checked whether this statement is the
same as for the previous result set. If yes, the old meta-data is re-used, if
no, a new instance is created.
Probably, a method like
XMetaData Statement::getResultSetMetaDataForStatement( String )
would do. It would be used in all places which currently access m_xMetaData
direcly (which would be forbidden then), and internally cache the meta data.
A class like (sketched only)
class MetaDataCache
{
private:
::rtl::OUString m_sPreviousStatement;
public:
MetaDataCache();
Reference XMetaData
getMetaDataForStatement( const ::rtl::OUString _rCurrentStatement );
}
would probably be the ultimate decoupling then :)
-
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 55884] [dev] clean up resultset/ statement/metadata relationship in various SDB C drivers
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55884 User fs changed the following: What|Old value |New value Keywords| |easy2dev - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 55884] [dev] clean up resultset/ statement/metadata relationship in various SDB C drivers
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55884 --- Additional comments from [EMAIL PROTECTED] Thu Oct 13 02:56:37 -0700 2005 --- Sharing the meta data is rather easy. Here is detailed instruction on how to do: 1) in the common statement base class (exact name depends on the driver), add a pure virtual function virtual XXXResultSet* createResultSet() = 0; (XXX is to be replaced according the driver's notation conventions) Some drivers, like the file driver, already have such a method. Just make it pure virtual then. 2) in the statements classes, replace occurences of = new XXXResultset(...); with = createResultSet(); in executeQuery() and similar functions code 3) in the ordinary statement class (which derives from the common base class), implement createResultSet() with code like return new XXXResultset(... , NULL); and in the prepared statement class (which also derives from the common base class), implement createResultSet() with code like return new XXXResultset(... , m_xMetaData); Explanation : a non-prepared statement has no meta data, it is generated by the result set when required, so we pass NULL. A prepared statement has meta data, which it can share with the result set it is currently constructing, so we pass this meta to the constructor. 4) in the result set, there's normally a member variable named m_xMetaData which is a reference to the meta data. Add an argument to the result set's constructor. Use this argument to initialize the m_xMetaData member variable. You are done, meta data is shared between the prepared statement and the result set. === Now the tricky part. Well, it is not necessarily difficult, but I just happen to have no really clear ideas about that now. Perharps it is very simple, at the end... The result set meta data is initialized by passing it the list of selected columns in the SQL query. This information is used, for example, to determine the number of columns or the name of the columns. In a prepared statement, this list of selected columns is known from the very beginning, when the prepared statement is constructed, because the SQL statement is passed to the prepared statement's constructor. In an ordinary statement, the SQL statement is known only when executeQuery() method is called. So it is the right time to start initializing the meta data. If the meta data is shared, the initialization might occur twice for a prepared statement. First time when the prepared statement is constructed, second time when the query is executed. This might have consequences or not, depending on how the initialization is done. Please notice that I did not say it occurs. I just suspect a potential problem here. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
