Using the Serializer outside of Spidermonkey (For storing data in Database)

Hello,

I searched a way to store some data in a database. Since the objects are transmitted trough spidermonkey i have already the Serializer setup.



The idea is to simple store the result from the Serialization process in a BLOB.



Well, there are a few problems i am not able to overcome,

I use following code for getting and feeding the data tought the Serializer:

[java]

public class db2Universe {

public static UniverseData loadUniverse(int universeId) throws SQLException, IOException{

UniverseData universe=new UniverseData();

String sql=“SELECT data FROM universes WHERE id=’”+universeId+"’;";

ResultSet result=DataBaseBinding.getInstance().evaluateQuery(sql);

if(result.next()){

ByteBuffer data=ByteBuffer.allocate(10000);

data.put(result.getBytes(“data”));

universe=(UniverseData)Serializer.getExactSerializerRegistration(UniverseData.class).getSerializer().readObject(data, UniverseData.class);

}else{

return (null);

}

return (universe);

}

public static void storeUniverse(UniverseData universe) throws IOException{

byte data[]={};

ByteBuffer buffer=ByteBuffer.allocate(100000);



Serializer.getSerializerRegistration(UniverseData.class).getSerializer().writeObject(buffer, universe);

buffer.get(data);

String sql=“INSERT INTO universes(data) VALUES (’”+data+"’)";

DataBaseBinding.getInstance().evaluateCommand(sql);

}

}

[/java]



As you can see i have no idea what i am dooing :wink:

What i can tell is that the storeUniverse() function might work, at least a 11Byte long BLOB gets stored. (11Byte seems a bit small since i store following object)



[java]

@Serializable

public class UniverseData extends AbstractMessage{

private int universeId;

private String universeName;

private String universeDescription;

private Vector3f universePosition;



public UniverseData() {

}



public UniverseData(int universeId, String universeName, String universeDescription, Vector3f universePosition) {

this.universeId = universeId;

this.universeName = universeName;

this.universeDescription = universeDescription;

this.universePosition = universePosition;

}



@Override

public String toString() {

return “UniverseData{” + “universeId=” + universeId + “, universeName=” + universeName + “, universeDescription=” + universeDescription + “, universePosition=” + universePosition + ‘}’;

}



}

[/java]



Has anybody already done such a storage system and can give me a hint?

I wouldn’t use the network serializer to store persistent data. It is not designed to do that and even a small change to one of the classes or adding another serialized class will make all of your previously saved data completely unusable.



Generally, if you are going to store data into a database then you should try to put it in real fields where possible. Where not, use Java’s standard serialization because when done properly it is much more robust through class version changes. The size will be bigger but you won’t trash your persistent data every time some little things changes. (Java’s serialization has mechanisms for managing class changes through different serialized versions and in some cases is just fine with field adds and removes, etc. if you’ve set you own serialver for the class.)

@pspeed said:
Or adding another serialized class will make all of your previously saved data completely unusable.


Uch, i did not know this drawback. Of course this is a K.O. criterion. I guess i hoped for that simple way so i do not have to write a database encoder/decoder for every object i want to store.
@zzuegg said:
so i do not have to write a database encoder/decoder for every object i want to store.

10 mins of coding, years of fun ;)
@zzuegg said:
Uch, i did not know this drawback. Of course this is a K.O. criterion. I guess i hoped for that simple way so i do not have to write a database encoder/decoder for every object i want to store.


If it's simple... a little reflection goes a long way. Otherwise, why bother to store binary blobs in a database at all.

But if you want to go that route, use Java's built in serialization. Some DB layers will even handle that for you.

Well, actually i already spent hours trying to store/read that damn ByteBuffer in the database. In the meantime i probably could have already writen all my current encoders :wink:

@normen said:
10 mins of coding, years of fun ;)


1 minute of copy pasting from normen and years of fun :D

(so copy pasting take 1/10 of coding :o)

xstream → object to xml then stora that in a text/blob field.

  • important variables like joiun criteriums as a normal field.



    I would not use java serializatzion for persitance btw, as there is no contract guranteeing compability between different java versions.
1 Like
@EmpirePhoenix said:
I would not use java serializatzion for persitance btw, as there is no contract guranteeing compability between different java versions.


This is not really true. If you store a lot of non-java.lang objects then you can run into this issue. Otherwise, the format is fairly robust for making sure you maintain version compatibility between one version and the next. It's the Swing classes that would frequently get overhauled and mess with people... but I always thought it was stupid to persist swing objects, anyway.

I have some serialized files from 1998 that will still load today.

I agree that XML or JSON is way better but it's also more verbose. And if you are going to go to the trouble to flatten the objects into a text form then most of the work has also been done to get it into proper DB fields. At that point, you might as well go straight to tables, especially if the objects are relatively flat.

I already had that problem with the jaa serialisation, if you switch between jdk 7 and jdk6 or openjdk bwteen oracle. So not the best choice.

@EmpirePhoenix said:
I already had that problem with the jaa serialisation, if you switch between jdk 7 and jdk6 or openjdk bwteen oracle. So not the best choice.


Which classes failed? Serialization footprint for most classes is part of the spec. If you do serialization correctly then it should be durable across compliant versions.