[SOLVED] password saving


#1
out.write(pwd, "Pass", null);

What is the best way to take care of an error in writing the password to file using jme Savable?

Null doesn’t seem right.


#2

What sort of an error?


#3

After looking at source I see defVal only get set if value is null.

    public void write(String value, String name, String defVal)
            throws IOException {
        if (value == null ? defVal == null : value.equals(defVal))
            return;
        writeAlias(name, BinaryClassField.STRING);
        write(value);
    }

I guess at that point it would be best to drop them into the login routine and make them reset their password.

Edit: Err I misread that. Value only uses defVal if value != null.


#4

Could you elaborate a little bit more on what you’re trying to accomplish and why the default values are an issue?


#5

That method rewritten in English, “if the value is null or is the same as the default value, then don’t write it because it’s a waste of space.”

Edit: oooh… and even I’m wrong.

"If the value is the same as default value then don’t write it because it’s a waste of space. "

The rest is just an odd way of checking if both value and defValue are null.

Edit 2: and this:

if (value == null ? defVal == null : value.equals(defVal))

Could be replaced by:

if( Objects.equals(value, defValue) ) 

…with no functional difference as I see it.


#6

After realizing I misread that thing twice, I finally understood what it was saying but not what it was doing. I’ve never seen this use of conditional operator before today. Thanks for saving me hours of effort with your explanation.

I don’t want to write a null password.

I will have to check pwd for null or empty string first and set user from playing to password reset if something goes wrong is what I am thinking.


#7

Gotcha. If you don’t want to deal with null I’d suggest using an empty string - then you don’t need to worry about null checks and any equals() checks will take care of the rest (assuming you disallow users from setting an empty password in the first place).


#8

I don’t understand the logic behind Savable,

    public void write(int value, String name, int defVal) throws IOException {
        if (value == defVal)
            return;
        writeAlias(name, BinaryClassField.INT);
        write(value);
    }

Why does it not write to file if value and defValue are the same?

If I am writing a player file, I definitely want value or defVal to be written to file, period. Just because they are both equal doesn’t necessarily mean there is a problem with value.

For instance, you create a new character, its level is 1, but you cant save that level if defVal = 1.

You wouldn’t want it to be < 1, but absolutely it needs to be written to file as at least 1.


#9

It’s not a problem with the value. It’s just a waste of space to write a default value… because you will default to that when reading if it is missing.

Then default value isn’t 1. Default value is something that it can never be… because in this case there is no default value.

I think you are totally misunderstanding what “default value” means.


#10

This may not sound right but this is what I get by reading everything and testing.

If there’s an error for write, you want to match the expected value that caused the problem with defVal so the write fails.

On read, you set your defVal to what you want the variable to be if there was an error on write because if you call the field name that wasn’t set on write, defVal is used.

That’s the only way the defVal actually comes into play. Failure to match the write value will result in the bad data being written to file.

For instance, you don’t want a null value for a string variable, use null for defVal on write, set read defVal to some value you find acceptable.


#11

Nope.

If you have a default value. It’s the default value for that field. So if you try to write the default value then nothing is written… because when you read the value and it’s not there then you’ll use that same default. Essentially, you are only writing what is different than defaults.

There are very good reasons to do this. 1) it takes less space if everything is a default value. 2) you may decide on new defaults later and your objects will automatically upgrade if they didn’t have specifically overridden values.


#12

I see.

Edit: Thanks again.


#13

After going back through a lot of the save stuff I realize now how the biggest mistake I made is being lazy and not initializing all savable variables to a default value. Totally misunderstood savable.


#14

I updated the wiki for saving .j3o files using your info @pspeed.

If you see a problem with this please let me know. Don’t want to get this wrong.