[Edvin]

You make a mistake Dan.. (sorry for saying this) . Why you started a new MySQL Plugin, since we/you had a good MySQL plugin, and also you could edit it in what ever way did you wanted. I don't protest agaist your plugin, and also i don't say that isn't good, but if you continue to work at BlueG's it will be more good, because you win time, and like Y_Less said:

Quote:

Originally Posted by Y_Less If you thought the existing code was ugly, why not just clean it up a bit? ...

Respect for the job also.

[Maxips2]

I actually don't see the point of making the functions similar to SQLite functions...

I think you should keep the beta 1 syntax, or a more common one anyway.

[Dan..]

Quote:

Originally Posted by Edvin You make a mistake Dan.. (sorry for saying this) . Why you started a new MySQL Plugin, since we/you had a good MySQL plugin, and also you could edit it in what ever way did you wanted.

I've already wrote the plugin. Now, all I have to is to mantain it and, in my opinion, this code is easier to read and it's more maintainable.

Quote:

Originally Posted by Maxips2 I actually don't see the point of making the functions similar to SQLite functions... I think you should keep the beta 1 syntax, or a more common one anyway.

I want to make it look like SQLite so code written for SQLite will be easier to be ported (e.g. Slice's BUD).

There isn't a very big difference. I've removed the "row" parameter (added a new function to replace it's functionability) and renamed a few others.

[Maxips2]

Why would you want to port SQLite to MySQL?

Anyway, perhaps make macros for that?

[Jay_]

Quote:

Originally Posted by Maxips2 Why would you want to port SQLite to MySQL?

It depends on the circumstances - I can think of a few scenarios in the past where I have wanted to port my SQLite database to MySQL purely for communication purposes. SQLite is a local embedded database engine, and as the name suggests it's only "lite" - that means complex tables packing loads and loads of data consisting of many advanced queries don't really meet the database engines goal as it's not designed for large scale production environments. Although technically it can be embedded too, MySQL generally is standalone. This makes communication with a MySQL database from an external source much easier. It also has performance tuning features and can normally handle large amounts of data much better.

[Kar]

So you made all yours functions without the row functionality and used strings (columns / field names) only and its faster? I thought using row indexes would've been faster.. Idk just asking

[TheArcher]

@Y_Less Even he is still developing a new MySQL plugin, why you guys are going against him? Users can still using BlueG's plugin as well as StrickenKid's one. You are not going to waste your time on testing but just him. So LOL.

P.S Dan is right somehow, for example BlueG's plugin is bugged and crashes for no reason sometimes..

[Maxips2]

Quote:

Originally Posted by Jay_ It depends on the circumstances - I can think of a few scenarios in the past where I have wanted to port my SQLite database to MySQL purely for communication purposes. SQLite is a local embedded database engine, and as the name suggests it's only "lite" - that means complex tables packing loads and loads of data consisting of many advanced queries don't really meet the database engines goal as it's not designed for large scale production environments. Although technically it can be embedded too, MySQL generally is standalone. This makes communication with a MySQL database from an external source much easier. It also has performance tuning features and can normally handle large amounts of data much better.

There is a point in what you are saying.
But I think that if you already chose to use a database then you would probably know which one suits for your needs.

If you are planning on using more complex queries and you need better performance or communicate your database from another source, then you should probably aim for MySQL at first place and not SQLite.

Besides that, I still think that porting from SQLite to MySQL, even with this plugin isn't going to be that easy, and will actually make it slightly harder for users who are used to the common syntax of MySQL functions (StrickenKid's and BlueG's MySQL plugin).

That is just my opinion of course.

[AndreT]

I don't see the code he used for testing anywhere, so cannot exactly say about the speed difference.

But well, I was just thinking, there are some spots you could address, such as why do you load the callback/format parameter data if you're not sure in the first place what sort of a query you're about to handle (some queries would not even require to allocate memory for these strings or pass them on to containers).

(By the way I got a plugin of my own released a bit hidden somewhere on my server's site... only the necessary stuff and adequate speed results... no idea why I'm saying this though)

edit 2: and yes, iterating through a set of strings and comparing them (although depending on the system architecture the comparisons can be very fast as well) will always be slower than accessing the row by its index.

[Jay_]

Quote:

Originally Posted by Maxips2 Besides that, I still think that porting from SQLite to MySQL, even with this plugin isn't going to be that easy, and will actually make it slightly harder for users who are used to the common syntax of MySQL functions (StrickenKid's and BlueG's MySQL plugin).

I don't think the author maintained the consistency between this plugins API and the in-built SA-MP database natives purely for the purposes of what you're suggesting.

In my opinion SA-MP's in-built database is much more logical and easier to maintain in some ways compared to other MySQL plugins, given the use of tags within the library.
Given some of the arguments that are currently taking place I'm not taking sides with anyone, but it's worth mentioning that this is the first plugin to finally feature effective result handling which is one of the most important aspects for retrieving data.

[TheSka]

All MySQL functions are the same of BlueG's plugin in this one? Or.. Those defined on your own?

[Dan..]

Quote:

Originally Posted by Maxips2 I actually don't see the point of making the functions similar to SQLite functions... I think you should keep the beta 1 syntax, or a more common one anyway.

Version 0.3 (not released yet) comes with a few aliases to replicate the natives in 0.1.

Quote:

Originally Posted by TheSka All MySQL functions are the same of BlueG's plugin in this one? Or.. Those defined on your own?

You'll find equivalent for (almost) each function BlueG's plugin has.

[TheSka]

If you want almost all the natives to be related with SQLite, why can't you make a SQLite plugin?

[RajatPawar]

I checked out the natives, and they are almost the same as BlueG's plugin ! Personally, it doesn't matter TO ME if it's 94ms or 80ms, it's just MS. (My opinion, so spare me the 'milliseconds are important in computers, etc' talk.)

[MP2]

One execution that takes 10 MS isn't a problem no - it's when you have many of them.

[Dan..]

Quote:

Originally Posted by TheSka If you want almost all the natives to be related with SQLite, why can't you make a SQLite plugin?

SQLite is already supported. This plugin adds support for MySQL using similar syntax.

[dnee]

I'll test and use it. Thank you for your MySQL Plugins.
I like to write MySQL Function this style.

[Dan..]

Plugin updated!

[dnee]

Can I stop mysql_log.txt ?

[dnee]

You forgot

Add in mysql.inc

Код:

#define LOG_DEBUG                        1
#define LOG_INFO                        2
#define LOG_WARNING                        3
#define LOG_ERROR                        4

native MySQL:mysql_debug(debug_level);

I've changed to LOG level 3 [LOG_WARNING]

Код:

OnGameModeInit()
{
mysql_debug(LOG_WARNING);
}