Force locale within PersistenceDatabase.setExp

[seberoth]

Hi,

it would be nice if you force the MessageFormat in PersistenceDatabase.setExp() to use Locale.US .

Like:

MessageFormat form = new MessageFormat(UPDATE, Locale.US);
Object[] args = {module.getAbbr(), player.getName().toLowerCase(), exp};
String sql = form.format(args);

At the moment it use the locale and e.g. in Germany the double is formated like 5,5 (comma) and not 5.5 (dot). Because of that the Update fails.

I hope you understand what I mean. (Sry for my bad english).

[cryxli]

Hallo seberoth - endlich guckt mal jemand den Code an :-)

I think, you've done part of the Issue #11 - review of the code out of necessity, of course.

Can you describe your setup, please? I'm especially interested in your DB configuration: Do you use SQLite or MySQL?

And, do you have any special settings that could change the behaviour of the code: E.g., I assume you're running Bukkit on Windows 95 with default locale German-Germany, de-de that is. (Note, in de-ch, some settings are different, actually)

Thanks for your help!

[cryxli]

@pablohess What do you know about encoding and formatting on JDBC level?

As stated in thw SAD, we're not relying on a DB abstraction layer. Have you ever heard about any best practice on how to exchange native queries (send from app to db) with special formatting, like floating point numbers...?

[cryxli]

QuickFix idea:

// li.cryx.expcraft.persist.PersistenceDatabase
private static final String UPDATE = "UPDATE ExpCraftTable SET exp={2,number,0}/100 WHERE module=''{0}'' AND player=''{1}''";
// ...
String sql = MessageFormat.format(UPDATE, module.getAbbr(), player.getName().toLowerCase(), exp*100);

Since floating point numbers cause the problem, simply don't use them. That way the query does not depend on a locale.

[cryxli]

http://www.sqlite.org/lang_expr.html#litvalue http://dev.mysql.com/doc/refman/5.0/en/number-literals.html

Floats use ".", always. So the idea with Locale.US will work for both JDBCs.

Someone told me, that already the SQL standard defines floating point number to be written with ".".