10.04.2013, 07:52
(
Last edited by Dan..; 06/05/2013 at 06:55 PM.
)
Quote:
Ok, seems like I have to tell you that this is somehow pissing me off. I have nothing against any plugin release, even if it is MySQL, but the way you have been handling this situation is quite annoying.
In January I decided to stop working on my plugin and you did ask me to continue it at some point. After some small fixes, additions and some code design changes ("java style", as you told me), you seemed to have lost interest. Now out of sudden you release your own plugin without any notice to me, which is the reason why I'm angry. |
Quote:
This seems to be some kind of joke to me, because you are still using snippets of my plugin. The only difference (in the way how the plugin handles the MySQL stuff) I can see so far is, that you decided to use std::maps<> instead of vectors/queues, but I don't want to get into a further investigation.
|
Quote:
1) This has nearly half the number of functions of BlueG's - how are there more features?
2) You say you intend for this to be faster - have you got ANY plans on how to do this? Don't forget that the vast majority of the (lack of) speed in any MySQL plugin comes from MySQL itself. Even if your section of the code is 10x faster than BlueG's - if 99% of the code is internal MySQL stuff common to both then you have only improved the total execution time by 0.9% 3) If you thought the existing code was ugly, why not just clean it up a bit? That's got to be faster than developing (and testing) a whole new one, then getting people to convert. 4) There isn't really such a thing as a "quick" query - even just a "SELECT * WHERE" still has to compile the query and search the entire database. There was a reason non-threaded queries were removed, do you have any numbers, of ways of assessing what is "quick" and not "server hanging". 5) In what world is "mysql_connect" similar to "db_open"? Or the other functions - renaming everything is not my definition of an easy conversion! 6) You also mentioned improved stability - how are you going to assess and prove that too? |
However, my plugin still has multiple result sets and non-threaded queries (even if you don't like them, I find them useful).
2. It's clear that I can't optimize MySQL's api, but I'll try to optimise my code as much as possible. The difference would be narrow, but it would still be there.
3. I felt bad editing his code. I thought it was disrespectful of me.
4. It's quick because it doesn't have to be passed to another thread, execute it and call the callback. It's again, a narrow difference, but it does exists. I'm using non-threaded queries in OnGameModeInit and OnGameModeExit to load and save everything. They look better and I don't care if the server hangs as long as my data is loaded. I had a lazy MySQL server which loaded data from the server AFTER players connected.
5. Not all of them are alike, but most of them: db_close, db_free_result, db_num_rows, db_num_fields, db_field_name, db_query, ~db_get_field (has one extra parameter, `row`), ~db_get_field_assoc (same with `db_get_field`)
6. I'll run some 'hardcore' tests? I've succeeded in crashing BlueG's plugin sending a huge amount of data. I'll try the same with my plugin.
Quote:
It used to crash my server 5-8+ times per day for months but I still continued to use it and still will up to this day. :P
|
--
You guys feed with hate. That's what I was afraid when I released this plugin.