Thread

Darn gnomes always dig’n up my closed db connections - I just planted them too!

I didn’t have a chance to answer this…

I have to blame school and my timezone 😛

Darn gnomes always dig’n up my closed db connections - I just planted them too!

:lol:

I didn’t have a chance to answer this…

I have to blame school and my timezone 😛

Frank was all over this man.  He was helping with the actual troubleshooting when the problem came up.  I didn’t think it would get solved that fast.I don’t know if Frank used a debugger or not, but that certainly speeds things along.

Sorry you didn’t get a chance. 

Randy

It’s all right. I do hope there will be a new challenge soon!

(if there isn’t, I do have a very hard one, concerning IR 😊)

If you attempt to send a query to a database using CI you’ll get an error.

So the question is:

1) Is this the expected behavior? (a fail safe)

2) If the developer purposefully invokes the close() method, should CI honor that request and not (somewhat blindly) re-open a connection the develop thought he/she had closed?

well, I think this is a multiheaded beast (hydra?)

1) That piece of code seems to be in there in the first place to open a connection if not already open, as if an inexperienced Coder just tries to invoke a query in his/her controller/model, and it will happily work, and we all agree - i think - that this is a good thing, even for experienced coders who just want to whip up something fast. the effect that it reopens a manually closed connection is a side effect from this.

2) data loss is bad. Whatever reason one might have had to prematurely close a database connection, if code follows which permits more data to be saved then this data should either be saved, or the programmer has the choice to actively destroy the db object which will throw a nasty error and bring the whole machinery to a grinding halt, which would have been the intention of said developer in the first place (try/catch anyone?)

3) it is relatively easy to set up the database close as a post-system hook or a shutdown procedure, which will clean up the resources at the last point possible/sensible. If memory consumption is an issue, you would destroy the whole object anyway, and not just close the connection. Closing the connection because of limited resources is futile as well, as it is ultimately not php’s decision anyway if the _system_resource_ will be freed or not, this has to be decided on the system-level.

4) cases you want to close the connection include for sure is serialization of an object and to an extend any variant of type-casting (__tostring as an example), after which the object will be either gone or just a copy would have been created, making the original obsolete and would be null’ed/unset anyway.

Therefor in serious scenarios I don’t really see the issue with the potential re-open of a per-design runtime permanent resource.. I see the advantage of limited data-loss, although i would mark up any action after my database-close as potential bug if i’d see it.

Well, as usual, just my 2-your-decimal-currency-of-choice, everything IMHO and AFAIK and some more acronyms I just can’t remember..

all best,
Frank

Cool…I don’t know a thing about Internal Revenue…jk man

But I don’t use IgnitedRecord either 😝

Randy

I submitted a bug report concerning the following key question:

So the question is:

If the developer purposefully invokes the close() method:

1) Is this the expected behavior? (a fail safe)

2) Should CI honor that request and not (somewhat blindly) re-open a connection the developer thought he/she had closed?

The bug report is here: http://codeigniter.com/bug_tracker/bug/5845/

——
Randy

haha 😊

But about database closing, is that really needed?
Because PHP closes the connection automatically on script exit (unless there is some kind of bug).

Frank was all over this man.  He was helping with the actual troubleshooting when the problem came up.  I didn’t think it would get solved that fast.I don’t know if Frank used a debugger or not, but that certainly speeds things along.

Randy

not wanting to pat myself on the shoulder too much or anything, but i do this kind of stuff since like 1996 (helped on the first ports of mysql to HPUX10.x and stuff like that) and these days I finance my growing family with (web)application development.. I didn’t use a debugger, I just read what the code is doing…

I actually like doing stuff like that, thats why i picked your first posting in the first place - if it is remotely interesting for me, i will read and try to understand it.

cheers
Frank

It’s all right. I do hope there will be a new challenge soon!

(if there isn’t, I do have a very hard one, concerning IR 😊)

well i have one about mptree and unnecessary pass-by-references-which-throw-errors-in-the-end 😉
is that download fixed now to the latest version?

cheers
Frank

edit: found the link to the latest mptree, no worries here, thnx for the cool model

well, I think this is a multiheaded beast (hydra?)

Certainly—they all seem to be…

1) That piece of code seems to be in there in the first place to open a connection if not already open, as if an inexperienced Coder just tries to invoke a query in his/her controller/model, and it will happily work, and we all agree - i think - that this is a good thing, even for experienced coders who just want to whip up something fast. the effect that it reopens a manually closed connection is a side effect from this.

Yes, and we can’t change this for sure.

2) data loss is bad. Whatever reason one might have had to prematurely close a database connection, if code follows which permits more data to be saved then this data should either be saved, or the programmer has the choice to actively destroy the db object which will throw a nasty error and bring the whole machinery to a grinding halt, which would have been the intention of said developer in the first place (try/catch anyone?)

3) it is relatively easy to set up the database close as a post-system hook or a shutdown procedure, which will clean up the resources at the last point possible/sensible. If memory consumption is an issue, you would destroy the whole object anyway, and not just close the connection. Closing the connection because of limited resources is futile as well, as it is ultimately not php’s decision anyway if the _system_resource_ will be freed or not, this has to be decided on the system-level.

Here we have a departure of thoughts.  I don’t want to propose that I know or can foresee the logic every developer will use to for “their” vision of the perfect application.  I do know that when viewed in the context of a state machine, I believe you logic is somewhat flawed.  For example, in the connected state, the dev can perform a set of operations in one know profile. In the disconnected state, the application can take on a completely different profile with different context altogether.  The DB object is relevant in both states, the connection the database is not.  However in your analysis, you’ve lumped them together.

Succinctly, if you destroy the DB object you also destry access to its methods and members that need to persist from on state to another (such as the DB Helper Class et. al.).

Perhaps it would be better to capture the state and test for that rather than simply testing for !$this->db->conn_id.  Something similar to !$this->db->active is just as simple, yet much more effective from a logic point of view.  It could capture the state of the machine rather than the state of the connection.

4) cases…

I truly appreciate your experience here. I personally don’t want to presuppose every usecase and say “there would never be a security reason…”

Well, as usual, just my 2-your-decimal-currency-of-choice, everything IMHO and AFAIK and some more acronyms I just can’t remember..

That’s what all this is made up of.  As I said earlier, this never impacted me why I didn’t see it right away.  It was odd at first and like you, I too believe the impact would be minimal if it were to stay as it is…I’m just sort of learly about the framework doing things on it’s own…behind the scenes, without telling us, and without us realizing what’s going on.

Best regards and thanks for the help,

Randy

... but i do this kind of stuff since like 1996 (helped on the first ports of mysql to HPUX10.x and stuff like that) and these days I finance my growing family with (web)application development..

Well, now that I know that you are a guru with no shame, then that crap you posted in the other thread was utter nonsense!  😝   hahaha

... but i do this kind of stuff since like 1996 (helped on the first ports of mysql to HPUX10.x and stuff like that) and these days I finance my growing family with (web)application development..

Well, now that I know that you are a guru with no shame, then that crap you posted in the other thread was utter nonsense!  😝   hahaha

I can send you the url to my shrine if you wanna, but worship is not free you know.. i demand devotion… 😉

You’re going to fit in really well here!  Just don’t answer too many of these challenges too quickly…it really gets under the youngin’s skin sometimes. :cheese: