Re: [PHP4BETA] odbc_close

Thies, I think what you are writing is wrong, to say it nicely. You started giving that advice a couple of weeks ago. Maybe that works for Oracle, but it messes up things with ODBC. From extensive system design experience, plus having started to look at this specific code, I can tell you from a guts feeling level, intuitively, that you are wrong. Are you even using ODBC yourself? I have to use ODBC all the time, in some quite complicated scripts, and I need it to work like a clockwork. I share interest in stability, cleanliness of design, etc. I agree that reference counting is a good thing in general. But I think there are some serious flaws in the logic you are using. For some things you use a wrench, for others a screwdriver. Using the wrong tool breaks things. As I have said in another message, a lot depends on whether you consider the odbc_result to be your access to get data from a statement on a connection, which hence has to go away when the statement is closed, or whether you think of it as an object of its own. I'd stick with ODBC's paradigm and just see it as access which has to go away. Why a new paradigm, if there is one that is known? If you don't like ODBC, don't use it. If you use it, use it as it is meant to be used. And if we'd adopt your way of looking at things, odbc_result having a life of its own, we'd have to do quite some coding to keep that object functioning reasonably. I _must_ close connections in a system where the number of connections is limited by license, and I _must_ close connections for many other reasons, including performance and improved concurrent use. I have to exercise extreme restraint to use nice words while I feel you are wasting other people's time with your advice in this context. You probably have good intentions, but I am afraid you only have understood half of the issue. There is a minor chance that I am wrong and you are right, but I'd be surprised that I'd be making a mistake at something I have been doing right so many times in other systems. My take on it is: I need php_odbc to work really well. What you are writing is 60% interesting, but also 60% wrong. Oracle is not equal to ODBC. Don't force something that isn't. To promise "all databases the same" might be popular to get votes in the next election, or to sell something, but it is wrong. If you really want them to be the same, access Oracle through an ODBC driver. Even if we think all men are equal we still can't force them to have the same shape noses, same texture of hair, and same skin pigmentation. Don't promise "all databases interfaces the same". That is a bad promise, we'd lose the specific powerful features they have. If you make everything the same, the least common denominator, you won't have any powerful features left. - Leo Baschy <nirvana@got.net> At 02:48 AM 3/13/00 +0100, you wrote: > i am convinced that using reference counting and dependicies > is a goodthing(tm) for php. > > if you need a connection|cursor to be closed just set it to > 0. that's easy. i actulally believe we should not have a close > call any more - being able to close something where some > other thing still has open references to it seems a bad idea > to me. (that is the way i implemented it in the oci8 driver) > > the real problem is that if we don't use reference counting > but depend on php request-cleanup code the order of cleaning > up is undeterministic. connections get closed *before* > statements etc - which can caus any kind of headache. > > when using ref-counting *all* resources will be free in the > _right_ order while zend destroys the symbol-table. that > basiclly means zend does a unset() on each var of the global > scope (function scopes have already been cleaned when returning > from them). another plus is that a result set will *work* as > long as you have a reference to it. > > tc