macid: corrupted state

[Kamil Dworakowski]

the error on start:

too few bytes. Failed reading at byte position 25

I deleted the last events file, and then it loaded fine.

It happens on windows, I'll check it later on my linux box at home. I
closed the console window that was running the process. Other
important bit is that the state in the app must have been last
modified a couple of hourse before I closed the window. I can
reproduce it easily. Any thoughts?

[MightyByte]

Usually when this has happened to me it's because the data that was in
state changed. If you are using this as state:

data MyState = MyState Word16

And then decide that you need support for decimal numbers, you might
change it to this:

data MyState = MyState Double

The state system will try to read the binary representation for Word16
as if it were a Double. If you need to make a change like this, you
either need to delete your old state and start empty, or you need to
migrate your old data.
http://nhlab.blogspot.com/2008/12/data-migration-with-happs-data.html
describes how to do a migration.

[Matthew Elder]

there is an open ticket for this to have a more meaningful error message.

--
Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com

[Kamil Dworakowski]

On Jun 18, 7:25 pm, MightyByte <mightyb...@gmail.com> wrote:
> Usually when this has happened to me it's because the data that was in
> state changed.

Messing with types produced me:

apprazor: Junk after checkpoint for state: Main.State

This does not mean that the msg I got on windows can not be an effect
of a an unmigrated state. I am pretty sure the types were fine though.
I'll check it one more time tomorrow. OTOH, I could not get it to fail
like this on Linux, which is a good news.

BTW, when I changed type of one of the fields from string to double to
check how happstack would fail ... it did not. It interpreted all the
strings as 0.0.

[MightyByte]

Yes, dcoutts and I were discussing this exact issue on #happs earlier
today. Errors from lack of migration show up at runtime and laziness
means that they don't always happen when state is loaded on startup.
Sometimes it runs fine until the offending data is used.

To fix this, we would probably need to embed some kind of
self-describing meta-data in the stored data. I actually just wrote
my first migration for a production site today. I haven't deployed it
yet, but these issues definitely cause for some worry. In my opinion
this should probably be a pretty high priority.

[awson]

State is broken on windows. More than a year ago I've posted the
solution here:
http://groups.google.com/group/HAppS/browse_thread/thread/435884193370578f/f4af9369fb5a6c52?lnk=gst&q=awson#f4af9369fb5a6c52.
Nobody have cared.

[Kamil Dworakowski]

I confirm that. Applying the patch provided by awson fixes it.

On Jun 19, 8:35 am, awson <meurgl...@gmail.com> wrote:
> State is broken on windows. More than a year ago I've posted the

> solution here:http://groups.google.com/group/HAppS/browse_thread/thread/43588419337....

[Kamil Dworakowski]

Here comes a patch for the happstack repo.

[Alex Jacobson]

Would a solution to the laziness issue be one where HAppS attempts to write the checkpoint to /dev/null at startup?

-Alex-

[MightyByte]

Possibly. It would make failures more reliable, which would help, but
it wouldn't solve the problem of data format changes where the size of
a changed data item is invariant (i.e. changing a Word32 to four
Word8s). The general solution is to include the schema (or possibly a
hash of the schema) as metadata that is part of the serialized data.
Something like Java's serialVersionUID (brief description towards the
end of http://java.sun.com/developer/technicalArticles/Programming/serialization/)
might be a suitable solution to this problem.

[Matthew Elder]

Can we get a confirmation that this fixes the behavior against the
0.3.2 tag? I will release a 0.3.3 when I can get a confirmation (with
this patch).

On Jun 19, 2:47 am, Kamil Dworakowski <ka...@dworakowski.name> wrote:
> Here comes a patch for the happstack repo.
>

>  state-winfix.dpatch
> 17KViewDownload

[Kamil Dworakowski]

yep, it is a good fix afaik

[Matthew Elder]

Did you test it?

--
Sent from my mobile device

[Kamil Dworakowski]

yes

BTW why do you create tags for happstack-{server,state,...}-version
instead of just happstack-version?

[Matthew Elder]

There is a possibility that we may release independent updates to each
cabal package as opposed to bumping everythying up. Esp in the case of
maintenance / bugfix version releases.

[Matthew Elder]

applied to dev and stable, released happstack-state-0.3.3 to hackage.

--