--- Log opened Tue Aug 04 00:00:54 2009
11:49 < burp> hi
11:49 < burp> happstack migrations are sick :p
11:50 < burp> or I'm not getting it right ;)
11:52 < burp> I want to rename some versioned Data, move it from one module to another
11:52 < burp> how do you suggest to do it?
11:53 < burp> I tried to make a migration which just reserializes the data
11:53 < burp> but the whole old data disappears
12:09 < Oejet> burp: You might get a quicker reply for that on the mailing list.
12:09 < mightybyte> burp: What do you mean by "rename some versioned Data"?
12:10 < burp> I have Plugins.Quotes.Quote Data and want to move it to Plugins.QuoteTypes.Quote
12:10 < burp> I missed separating functions and data/types
12:11 < mightybyte> Oh, you don't have to do a migration to change packages.
12:11 < burp> but "Plugins.Quotes.Quote" is hardcoded in the state file
12:12 < mightybyte> You don't need to migrate as long as your actual data does not change.
12:12 < mightybyte> burp: Hmmm, I didn't realize that.  Let me check my satte.
12:12 < mightybyte> state
12:15 < mightybyte> Yep, it is.  So the question is whether that actually matters.
12:15 < burp> it does ;)
12:15 < mightybyte> Ok, I'll take your word for it.
12:16 < mightybyte> What version is your current (pre-migrated) state?
12:16 < mightybyte> Is it just the default version?
12:16 < burp> its one further, 1
12:16 < mightybyte> Ok
12:17 < mightybyte> So you've already done one migration?
12:17 < burp> yes
12:17 < mightybyte> Well, you should be able to do this migration just like you did the last one.
12:17 < burp> hm, yes
12:17 < mightybyte> Just duplicate your current state in the new module.
12:19 < mightybyte> Then write "instance Version Foo where mode = extension 2 (Proxy :: Proxy OldFoo)"
12:19 < burp> instance Migrate OldQ.Quote Quote where
12:19 < mightybyte> And "instance Migrate OldFoo Foo where migrate (OldFoo a b c ...) = Foo a b c ...
12:19 < burp> migrate oldq = fst $ deserialize $ serialize oldq :: Quote
12:20 < burp> or that yes.. it _should_ work ;)
12:20 < mightybyte> If it was me, I wouldn't use serialize/deserialize
12:21 < mightybyte> ...unless it would be a large amount of work to construct the migration function.
12:22 < burp> before I see Plugins.Quotes.Quote in my state file
12:22 < burp> my checkpoint
12:23 < mightybyte> Yeah
12:23 < burp> after making a new checkpoint with new version:
12:23 < burp> Plugins.QuoteTypes.Quote
12:23 < burp> but all data is lost.. ;)
12:23 < mightybyte> Hmmm, very strange
12:24 < burp> <Oejet> burp: You might get a quicker reply for that on the mailing list. <- I might do this
12:24 < burp> these migrations are a pain because of hardcoded module names
12:25 < mightybyte> Yeah, I didn't realize the module names were serialized.
12:27 < mightybyte> Hopefully this would be addressed along with the "hash of the type structure" issue mentioned here: http://groups.google.com/group/HAppS/msg/0f3bc11493108a8a
12:28 < burp> hash of structure sounds good
12:29 < burp> http://paste.railsbox.eu/show/p65jUvfssMrDbytdi0Xc/
12:29 < burp> this is basically it
12:32 < mightybyte> Oh, this may be the problem
12:32 < mightybyte> I think you should have:
12:33 < mightybyte> mode = extension 2 (Proxy :: Proxy Q1.Quote)
12:33 < mightybyte> And set Q1 properly
12:34 < burp> you mean because Q0 was used that way in Plugin.Quotes?
12:34 < burp> I didn't export Q0 at that module
12:35 < mightybyte> You're migrating to Plugins.QuoteTypes from Plugins.Quotes, not Plugins.Quotes_000
12:35 < mightybyte> Oh, never mind.  Your import is doing it correctly.
12:35 < burp> sadly yes
12:37 < mightybyte> So you want to keep all the subtypes (Qid, Name, Qdate, etc...) in Plugins.Quotes still?
12:38 < burp> yes, as they stay the same
12:38 < burp> or is it not the way to do it?
12:40 < burp> it's interesting that just BotState1.BotState and Plugins.QuoteTypes.Quote ( and Plugins.Whatis.WhatisEntry from another plugin) are hardcoded in the state file
12:40 < burp> and not the subtypes you mentioned
12:40 < mightybyte> Maybe that's because they are Components
12:41 < burp> hm, right
12:41 < mightybyte> So maybe there would not be an issue with non-Component parts of state moving to new modules.
12:41 < mightybyte> brb
12:55 < mightybyte> burp: Well I don't see any obvious reason why what you're doing shouldn't work.
12:55 < mightybyte> ...unless maybe these migration issues apply differently to Components.
12:57 < burp> ok, thanks
12:58 < mightybyte> Ohhhh
12:58 < mightybyte> Maybe you need to do something different with the initialValue part of the Component instance.
12:59 < mightybyte> I bet that's the problem.
12:59 < mightybyte> Since there isn't any instance of this component in your state right now, it doesn't do a migration, it just uses initialValue.
13:02 < burp> hm, and the previous migration worked because of the same module name
13:03 < burp> that is probably it
13:03 < mightybyte> Yeah, I'm thinking so.
13:04 < mightybyte> And I don't see a nice way to get around it off the top of my head.
13:04 < mightybyte> So this would definitely be a good one for the mailing list.
13:04 < burp> =)
13:07 < mightybyte> And since initialValue is a pure value, you're somewhat limited as to where you can get it.
13:08 < burp> I'll fix this whole issue for now by using Quotes.hs for the types and QuotesSomethingelse for the functions
13:08 < burp> so the component keeps the name
13:09 < mightybyte> You might try manually editing the checkpoint file to see if you can do the conversion that way.
13:10 < burp> just changing the name with an editor destroys it, I'd have to dig deeper into the serialization format
13:10 < mightybyte> Ok, too bad
--- Log closed Wed Aug 05 00:00:55 2009