Discussion in 'Bukkit Help' started by rmb938, Jan 7, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    How would we go about adding a SQLite database or MySQL database to our plugins? The reason I ask this is because you need the sql driver so you can connect to the databases. Problem with that is craftbukkit takes any jars in the plugins folder and tries to use them as a plugin. That kinda gets messed up when you need to include a JBCD .jar for it to work. Can someone explain to me how I would go about adding SQLite to a plugin without this issue?
  2. Offline


    Dont use SQL.

    It complicates things fir your users, and makes things more difficult. In fact, some hosts will charge you for using it, so in the end it costs people money if you add this.
  3. Offline


    SQLite is flat file, there are no additional charges, no additional servers to run. And if your server is charging you for MySQL access is probably is a shared server and you wouldn't be wanting to run minecraft on those anyways.

    If you are working on an existing plugin I think is best to use the existing file code until we know for sure what Bukkit will offer. If you are making a new plugin I suggest looking at what existing plugins might be using, such as big brother.

    You can also try and find a database abstraction library, code to that, and leave SQLite or MySQL up to a small config file.

    EDIT: Sorry I misread your post. I know BigBrother uses an SQLite library and has it placed in the "root" directory.
  4. Offline


    Yup I figured it out just had to include the jars in the build
  5. Offline


    I don't believe any VPS company I have seen charge for SQL unless they manage it for you?
  6. Offline


    Actually SQL is better in most cases. All you really need is commands ingame to change settings and stuff which actually makes things easier for users. Plus most if not all webhosts now give you mysql for free and on a vps you are free to put what ever you want as long as it doesn't violate their TOS.
  7. Offline


    And said hosts usually also overstuff their servers in an attempt to squeeze as much money out of their customers as possible.

    SQL is and always will be faster than trying to work with flat-file databases.
  8. Offline


    The only reason I personally would ever use a flatfile is for basic settings that can't be set after the plugin is loaded but other then that its SQLite.
  9. Offline


    If it cant be managed from a ssh console it has no place in bukkit, if bukkit is to serve the community.

    The fact is that an ssh connection is the most common manangment intrerface you get with hosts that support minecraft, and if you do not support it you do not support most of peoples servers. You should not expect people to switch hosts, switch ip's, and risk losing their entire community, etc just because somebody wants a php based interface and needs a db to do that. Some of us value our communities more then shiny things like sqllite, and the bukkit team needs to remember that the community is what powers these servers and unless they cater to the needs of the people running them bukkit is worthless.
  10. Offline


    You can use ssh to interact with sql.... And what does switching isp have to do with anything? Now I am convinced you are just FUDing
  11. Offline


    Yea. Dude SQLite and MySQL doesn't mean you need to switch ISP or hosts. ANY VPS/DEDI you buy you can put w.e you want on it. When you buy a vps for dedi its yours. Unless it violates copyrights hosts/ISPs don't give a shit what you put on it.

    Also if you use linux you probably have set up LAMP which means you can easilly install phpmyadmin or any other form of SQL viewer
  12. Offline


    There are such things as prerequisites. Reinventing the wheel because someone can't choose a decent hosting provider is unrealistic. SQLite is probably the most basic of RDBMS's - if even it isn't supported, then a response of "tough luck" is totally appropriate.

    Not to mention, SQLite is bundled into PHP itself; you can work with SQLite databases natively in PHP 5 (though it's preferred to use PDO), without installing any additional software. Therefore, SQLite will ALWAYS be working in PHP if your host has a supported release installed.
    So, if you can't get an SQLite database working, sucks to be you. You should have done more thorough research on your host beforehand; stop spreading your unreasonable and uneducated FUD amongst the less knowledgeable members of the community.
  13. Offline


    Not to mention putting libs into the plugins folder is a bad idea.. it only makes looking in the folder harder and very disorganized
  14. Offline


    No its not. First of all, PHP has nothing to do with this discussion; You may like the idea of a PHP based administration interface.. but some dont - I did not - and thats fine. The big thing here is choice; I want the power to use a simple ssh based linux bash shell prompt, like I d now, because it is the most basic and functional way to manage a server, and in my case, I dont have a domain or apache on my box running my server and I dont WANT any of that running on my server.
  15. Offline


    Then don't use them.

    Problem is, you are trying to restrict plugin authors from using a database when the situation calls for a database; this means the design of the plugin is a thousandfold more complicated, more prone to errors, and more user unfriendly. Most people aren't willing to deal with the amount of problems that will arise just because of a sloppy design that manages to work around the lack of a database server.

    Believe me, I've actually tried to do this myself, as a personal experiment. I attempted to code a blog system that was entirely flat-file; designed to work without a database server at all.
    It was slow, inefficient, and extremely restricted in functionality.
    Without using a database, one must:
    • Load all data manually using file functions
    • Parse data files (usually CSV or another simple format) and organize the data input into the proper variables
    • Process data input manually, most likely by iterating over all elements and reacting to present data -- for example, one would have to loop over all blog posts in order to put together a "tag cloud", and then loop over blog posts again to create the list of "recent blog posts"...and even more than that.
    • Handle any user-interaction and data submission, and if new data must be handled, process it, rebuild the necessary data files, and overwrite the old data files without having a race condition occur (what happens in a race condition is that you are saving two different sets to the data at once; one set of data is guaranteed to be lost)
    All of the above steps are handled by the database server in a fast and efficient manner; multiple data submissions and requests can occur at once without running into file locking issues, race conditions, etc.

    I can assure you, attempting to make something that NEEDS a database work without one is entirely, absolutely, and fully impractical.

    If the plugin needs a database, it should have one. Period.
    If you don't want to provide it a database server, then you shouldn't use the plugin.
  16. Offline


    Once again you either grossly miss my point, or are trying to miscommunicate the issue to skew the discussion.

    If a plugin really needs a db, use one. Use a real db like mysql that can be administrated from the command line on a ssh connection, not a half-breed piece of crap that diesnt have any real interface except its own api.

    But the core of bukkit? It should not use a db at all.
  17. Offline


    crosspost from the other thread:
  18. Offline


    Dare I point out that you could simply use the sqlite (or sqlite3) command to edit your database with SQL?

    The same argument technically applies to MySQL - you use the mysql command to access that from SSH, you use the sqlite (or sqlite3) command to access SQLite from SSH.
  19. once again you derail a SQL thread. Get out. Now.
    SQLite can be admistered from a god damm command line/ SSH or any CLI you choose (hell i've seen it done over a freaking serial connection to an openWRT router!)

    for the love of god please stop diseminating false information to the community and trolling us.

    also fever if you use any browser apart from IE, I suggest you uninstall it and it's "half breed" crap.

    Got an iPhone? or ANY android phone? chuck that crap in the bin too!
    Mac OS X to.
    and Adobe reader.


    OT: you would need to inject the SQLite jar into the classpath somewhere, possibly in the command line.
  20. Offline


    For the record, I must admit I was ignorant of the sqlite3 command. My bad, lets move on.

    Still, I shouldnt have to know sql to update a single config value in my server - Granted, I do, and a few dozen more languages besides - but most users will not and it is them I am putting myself in the shoes of.

    Its called compassion for users. ;)
  21. Offline


    No, however things like users.txt should probably be in an SQL database.
  22. Offline


    If you put everything in SQLite, it'll be trivial to build web/command-line tools that make changing the settings even more user friendly.

    I've already rolled my own SQLite integration for my plugins, so if there is any area where help is appreciated just point me in the general direction.
  23. Offline


    We are still discussing how to best go about doing this. Anything posted by ANYONE but myself is not considered Official.
  24. Offline


    Can anyone post some information on how to include SQL into plugin? I have never done this before.

    Some snippets would also been nice.

    Or perhaps a source for plugin that uses SQL or SQLLite?
  25. Offline


    What exactly were you fighting about here?
    Of course Bukkit should provide real database support, if configured so. But of course the core shouldn't rely on it.
    The community is used to files and it should be kept that way, especially for not so advanced users.
    But many people prefer databases. And those should be able to use them.
    Why not just provide a general interface for handling data? Plugins don't have to worry about it anymore, you can just select which you prefer, everything fine.
    Easy to implement, easy for plugin writers, easy for for users, best possible solution in my opinion.
  26. Offline


    So, any suggestion? It seems like this discussion has been going on for ages. I agree with exec that both should be an option, but that might defeat the whole purpose of using (My)SQL(ite).
    I think we should just settle for some really simple interfaces for some special purposes and throw away the whole idea of primary-keys, indexes, foreign keys and joins. Those just can't be supported by text-files in a proper way.
    For example two simple interfaces: configurations (key/value pairs) and lists (multiple rows, each row having multiple values).
  27. Offline


    You're right, keys are hard to handle with text files, but when do you need indexes really anyway? And if a plugin really needs them in the future it can use them after all, but to use this plugin you need a proper database, that's it. Or this plugin has to handle them in some way.

    Yea, two simple interfaces sound good. For configurations maybe also a plugin column, so it's unique, easier to find, and sort.
    And then a general data interface to save any datasets.
    Both intern in one "database" and we have a pretty nice system.
  28. Offline


    Yes, exactly, some will use that to increase performance, but that only goes for REALLY BIG tables. I mean absurdly big. Normal tables can also be preloaded for performance-gains.
    I was more thinking toward putting configurations of each plugin in separate files. Also 'tables' would be separate text files (if text-files was used as the data-storage), each in the data-folder of their plugin.
  29. Offline


    Right, every table is a single files of course, and in the case of configurations separate files are better as well. But in a database one configuration table would be much cleaner.
    The configurations would just have to be saved in different ways (plugin col or plugin file, depending on sql or txt).
  30. Offline


    You really have to get a lot of data in your flatfiles for a MySQL database to be more efficient than flatfiles. Remember, you have the MySQL overhead to deal with too. No point if you're running less than 20 users and using simple plugins that do not have much data in them. Plugins like the Stats plugin from hMod is a good example of where you may want to use SQL.

    sqlite is better used for these situations, but again, you really need large flatfiles.

    Ease of editing the data is admin specific. For me, its damn easy to ssh in and vi a file. More complicated to do so on an SQL database, but easy enough as well. It really depends on what you're used to doing.

    Plugin authors should offer BOTH methods to us admins. I do not have many users on my primary server, so I don't need SQL. Plugin authors should also allow methods to convert from one method to another as well. Should I increase the amount of users on my primary server, I would look into having SQL then, and would need a way to import my flatfile data.
Thread Status:
Not open for further replies.

Share This Page