Flatfile

Only problem I see is people trying to run log block on flatfile >_>

 

Just look at my picture, with that solution there is no more worrying about anything like your problem.

 

@Sky.NET i didn't talked about anything you said, but about the fact that flatfiles are gone.

 

We also have the problem of bukkit being multithreaded. If plugins are more integrated but manage their own databases the risk increases of race conditions and other threading pitfalls. I can't count how many times I had race conditions in my own irc bot from my own inexperience, and I'm the only author of that! Nothing can stop a plugin author from doing what they want, but I think it would benefit all if there was one plugin/library/core feature that can provide this for plugin authors.

One of the best database abstractions I ever used, which I may stick my neck out and try and implement in java for bukkit, was python's sqlalchemy. In it you define and interact with your database structure using standard python code instead of using sql directly. Setting up a table is as simple as

Code:

>>> from sqlalchemy import Table, Column, Integer, String, MetaData, ForeignKey
>>> metadata = MetaData()
>>> users_table = Table('users', metadata,
...     Column('id', Integer, primary_key=True),
...     Column('name', String),
...     Column('money', Integer),
... )

You then make a class with those member variables. Making a new user and saving it to the database is as simple as

Code:

>>> ed_user = User('ed', 100)
>>> session.add(ed_user)
>>> session.commit()

I'm very new to java and I've been unable to find something similar in a quick google search, but, in my inexperienced opinion, might be a good option to look into.

 

First, sorry Sky.NET, I assumed English was your first language, I didn't realize you were German.

Second, I hate to continue the fight, but it's not the Bukkit team's job to teach people how to make good code/ensure that they do make good code. It's the programmer's job to learn how to code well. I agree that that example you gave was jibberish. That's why you don't MAKE jibberish in configuration files. Look, I can make jibberish in MySQL, too, just as easily!

Code:

+------------------------------------+
| blarghaflargh | Lolz  | fflawijfjw |
+------------------------------------+
| dkkdkdkdk     | true  | jabjjbj    |
| d3314         | false | dadfkj     |
+------------------------------------+

The point is that it's up to the programmer to make efficient code, and the user of the plugin to let the programmer (and other potential users) know when something is wrong/bad.

Flatfiles do not need to be readable by the server administrator unless they hold configurations. For example, my IronDoorLock plugin stores data about the ownership of doors placed in the map in a flatfile where each line has the following format:

"x(integer) y(integer) z(integer) ownername(String)"
E.g. "93 64 -50 AnonymousJohn"

It makes sense to the plugin, and runs faster than any other format because that's exactly how it's stored in the dynamic list used in the plugin (to prevent needing to read the file every time someone does something with the door). It's stored this way in the plugin because all I need to do to read it is call the stored String's split(" ") method, then check for equality between the items and the parameters I'm working with. All I need to do to set an item in the list is concatenate a string with spaces in between the parameters.

It doesn't make sense to the server admin, but that's alright because he doesn't need to know what it means. All he needs to know is how to use the in-game commands to set data, and that's pretty clear. Luckily, if the admin does do something he shouldn't with the file, in the method I have to read the file I ignore any line that doesn't follow that format.

Every data file format doesn't need to be the same because the format should be the one most suited for the plugin. The one that makes most sense to the plugin. Not the one that makes most sense to the admin of the server.

Configuration files, on the other hand, should follow the format most easily understood by the most unintelligent admin (well, to a certain extent). This is because it should only be read once, at the loading of the plugin (in the onEnable() method), and needs to be easily modified by the administrator. It is up to the plugin programmer to provide a readable format for this file, and if he doesn't, it's the job of the users who test it to tell him it's unreadable (and then the programmer's job to fix it). A typical (and actually VERY readable) format for a config-file is as follows:

Code:

#This is a comment, probably used to help describe an option better.
#The descriptiveoptionname option allows you to tell the server
#somethingtodo. Possible values for clearlydefinedvalue include
#someexamplesofvalues.
descriptiveoptionname=clearlydefinedvalue

#Example:
#The redstoneopensdoors option tells the server whether to allow
#redstone to operate doors or not. A 'true' value means to let
#redstone charges to open/close doors, and a 'false' value means
#to prevent said operation.
redstoneopensdoors=true

There are other good formats, such as the one described by Afforess (that one's a little more readable, but probably a little less easily read by the plugin itself).

I agree with the idea that Bukkit should allow the admins to tell it what format it should store data/configurations in, and that it should provide the option to the programmers to tell it what data/configurations to store/retrieve (and then it would store/retrive the data/configs in the format the admin specified), but there's no way to prevent the programmer from using his own way to store data. You should be careful, though, before saying any one way is the best way and that everyone should be happy with it.

And actually, an hMod/Bukkit plugin is the PERFECT place to learn how to code! It gives real-life example of how coding is put to work, and provides real-time feedback of what you can do better.

Also, it seems you've just switched your stance on flatfiles. I remember the line the most pissed me (and some others) off about your first post was the people who used flatfiles were dumb and shouldn't program plugins. Now you claim you never had a problem with flatfiles in the first place. If your real problem is (and was) with badly-formatted "plain-text files," you should have specified in your original post.