dbcore.mysql

[DeletedUser]

Originally Posted by Eglin

Yeah, of course there is no guarantee that the values returned will relate to your query as opposed to another thread's activities.

Ok, that i just dont understand *at all*. It is 100% guarenteed that it'll be your variable. It is not a member variable that is being returned, you are passing in a memory location for RunQuery to throw the response, it's your responsibility to make sure that the location is valid and wont be overwritten until you're done with it, not DBCore's. Look at the flow a lil bit more, it's not returning a memory location allocated by DBCore where it stored the value, it's asking for a memory location allocated by the caller where you want it to be stored. No probably involed, cant code based on "probably wont happen" (we have people running servers on multi-processor machines, it would happen).
Look and you'll notice that the memory space for errbuf or errnum is allocated in the calling function, then a pointer is passed to RunQuery(), therefore there are no overwrite issues within RunQuery

Originally Posted by Eglin

I just quickly scanned for places where it returned false and noticed that errnum was being set to UINT_MAX and errbuf to "DBcore::RunQuery: No Result" in one instance without really paying attention to what conditional branches were necessary to get there. I was probably just looking at a sanity check.

Yep, sanity check. If you pass a result variable to RunQuery and it doesnt return a result (ie, was an insert, update, etc), you'll get that error. errno is set to UINT_MAX on purpose because it's not a mysql error, it's a RunQuery sanity check error.

Originally Posted by Eglin

Yeah, I see that now. My original post was written under the incorrect assumption that mysql_use_rows was being used, rather than mysql_store_rows.

Not just talking about the result data, the errno and errbuf memory spaces have to be allocated by the caller, that's how there are no issues about them being overwritten by other threads, and no issues about when they should be freed (within the DBcore code, you still have to worry about that in the calling function of course).

Originally Posted by Eglin

DBMSs have large teams of very smart people working on concurrency issues. I seriously doubt that it is going to be possible for any client application to be able to outdo them on this front using their own api. Even substandard (in terms of functionality) DBs like mysql have at least rudimentary support for transactions and rollbacks and row locking and all kinds of other goodies to deal with precisely the type scenario that you mention.

Hehe, completely different topic than i was writing about. =) I was reffering to within our code, not on the server.

Read the code some more. I cant figure out if we're discussing coding theory or the DBCore class, because all of the "errors" you've mentioned in DBCore so far have just been you misunderstanding how it works (or just not caring to look), not a flaw in the code.