That's right, bitches! This one is stable! I think it's time to work on the timers ... Get that working before we can release 0.4.0. Ripnet, want to give that a shot?
I need to work on refactoring the modules, because I want to make sure they can register for packets as well, along with their sub modules.
Haha, thanks for the help ... Like I said man, keep up the good work!
i will :] This will be one insim project that i actually plan to stay with till the end... i'm still working on my cruise plugin... i finally got all the kinks worked out that i had with Remote MYSQL crashing Prism....
P.S. Am i an official PRISM Dev? reason i am asking is i have read + write powers for the PRISM GIT
Interesting, I was thinking about making a universal PDO interface for PRISM, like spinning it out to a module so everyone can use the same interface structure that's handle by PRISM at the base level. But I really don't know what to do. I know I really should have a single point for MySQL, and SQL in general, interface so that it's standard across the board, but I don't know what to implement.
Should it just be a simple persistent MySQL connection, through a PDO interface that all plugins and all modules can use, or should be go another route where every pluging uses their own interface. (I think that could get messy, so I don't want to do that, but that's what will happen unless I come up with a solution.)
Drawing from experince, I would use the AMX Mod X & Source Mod model of doing it. Let the plugins read from the config files and let them make up their own mind what should be allowed and what should not be allowed via SQL permissions. But they also had to build their on MySQL module in C++ so that it could be used by the SmallC plugin or Source:Pawn plugins. I don't have that problem.
I think I'll provide a basic addon module that will basically just extend PDO in a very simple way, in that it just starts the connection on startup of PRISM (with the module loaded) and keep it's self in a protestant state. If it has any problems I use the Exception system so that they can be handled by the plugins (and their programmers) and not just seen by the user / admin.
I can do alot better with PRISM then I have been doing, and I think that's my new years resolution. To be a better programmer so that everyone can learn from the open source code that I'm producing along with the PRISM development team. (Because, you're all so kick ass for taking time and helping me with this.)
well my problem was even though i used Mysql_pconnect it still seemed to find a way to lose connection to the mysql server... i had to end up going back and call mysql_connect every time the mysql was needed... the only reason i am using remote mysql is so i can pull up stats on my team website...
but beside the few crashes that i had when i first added the mysql to the plugin i haven't had any problems at all
Yeah, Pconnect really was never meant to be used in this way. Pconnect assumes that your using the connection between page loads, and it holds the connection in the background. Where as we run in memory all of the time we don't really use Pconnect ... But I will have to send keep-alives every now and again to the connection in the background. I guess I'll be sure to add that to a timer, every 300 seconds should be able to keep the connection open even if I'm not doing anything with it.
nope, my save timer was every 5 min, by the time that 5 min hit it had already lost connection... this is what i had originally tried then i tried pconnect... which didnt woek... so i ended up having to call connect everytime the connection was needed
I think it is about time that I began a decent level of work on my racing system. I think I am going to write it as a plugin for PRISM *nods*.
Are you going to be releasing a centralised MySQL connection between the plugins any time soon, or should I just write it using a function that I can alter to use the centralised connection afterwards?
I don't want to hold you back, so use you're own system for now, and when I release the next version you can just swap over. It should be pretty easy to do.
The PHP Data Objects (PDO) extension defines a lightweight, consistent interface for accessing databases in PHP. Each database driver that implements the PDO interface can expose database-specific features as regular extension functions. Note that you cannot perform any database functions using the PDO extension by itself; you must use a database-specific PDO driver to access a database server.
MySQL is supported by this interface, so there is no need to change anything really, just the way you start your connection, and any database function call should go through this interface.
I really don't like the PDO, it sucks to program for in the context of PRISM. If anyone has any ideas I'm willing to listen. (filur, ripnet, & Victor I'm lookign at you guys.)
oh wow i checked this right as you posted... any who... i may as well just build off of what i'm doing now then... depends what is more stable/quicker though
I would suggest that PRISM should only provide simple storage for key/value pairs and maybe serialized objects. If a plugin wants or needs more advanced storage they can implement it themselves.
not sure what your plan was. Do you want to code something that allows people with zero sql knowledge to use a database?
Or did you want to use PDO at first because it would provide a constant interface with any type of database? Iirc, it doesn't do that 100%, which is why i didn't like it either, so I wrote my own database abstraction class. Never really finished it though, because I don't use anything other than mysqli, so that's pretty much the only thing it contains at the moment.
Keep on working, I look forward to seeing how you manage your system and what I can learn about common use patterns from your code.
It feels like that's the easy way out. It would be, but I don't think that's fair to the people who started using PRISM. I will get PDO support I just have to think of a good way to impalement it so it's not insane for everyone. I think I have a lot of programming ahead of me.
My thoughts that it should have a common interface for all of the databases. I don't think it was a good idea to provide an abstraction layer, because well for one thing I would need to be good at all SQL languages. So a simple interface to all would be better. Also, I don't want to force people to learn a whole new API just because they want to use the common interface for PRISM's database. I think that everyone will have to write their SQL querys to be portable across all platforms and interface types. I use MySQLi exclusively as well. I find it to be the simplest solution to all of the problems. Should I just restrict PRISM to just use MySQLi as that's what we both know? Or do you think that adding PDO support will really add something to the project?
I guess you want to have PRISM-DataBase handling code, so that for example plugins can be distributed without any db handling code, because they all use the db code provided by PRISM?
Well, other than that I cannot think of why you'd add db handling code otherwise... but yes the problem is that you're forcing ppl to use another interface that they're not used to. But if you want unity in db handling, you'll have to force people to use your db handling code I think.
However, this doesn't have to be very obscure either. You can write a db abstraction that looks almost identical to PDO (but you don't use PDO), so it's not totally unfamiliar. You can start to write that only for mysqli and perhaps others can add abstraction code for other db types.
That was pretty much the idea behind my own db class. You create a db instance with a factory function. In that function you say what type of db you want to connect to and then that function returns a db object handle.
The db object has methods that looks pretty similar to pdo, so they shouldn't be very hard to learn. Though admittedly I've also added methods that make large arrays easier and quicker to retrieve... I think that breaks with pdo .. but anyway, that's details at this point.
so in short, you can create your own 'PDO'. If you don't deviate too much, then it should be simple for people to use it, because most of it will look familiar.
