On Tue, Oct 11, 2011 at 2:33 AM, Yanni Chiu <[email protected]> wrote:
> On 10/10/11 2:43 PM, Mariano Martinez Peck wrote: > >> >> On Mon, Oct 10, 2011 at 6:50 PM, Yanni Chiu <[email protected] >> >> For the case where a lot of serialized files need to be converted, >> having two versions in memory is almost a necessity; >> >> >> heheheheh how people could live with ReferenceStream for 10 years? >> >> otherwise, the Fuel code update would have to be applied for each >> file being converted. >> >> >> but answer my question: why would you need to update Fuel so frequently ? >> > > I don't need to update Fuel frequently. I'm currently "stuck" at some > pre-1.6 version of Fuel (some combination of package versions that I managed > to get working at the time, using early Fuel releases). You are an early adopter!!! cool :) > I want to migrate to a newer version at some point (to use some new Fuel > features), but the hold up is that I would have to migrate about a dozen > serialization files - probably manually, since a dozen is roughly at my > threshold to automate. However, I expect that the number of files to migrate > would be a larger number in the future. At that point I'd automate the: > deserialize with old Fuel, update to newer Fuel and serialize again. Exactly. That's what I meant. From my point of view it is easier to provide such scripts rather than to find a complex automagic conversion between versions. Imagine something like: FuelMigrator migrateFromFuelVersion: '1.6' to: '1.7 streams: aListOfStreams basically it can use gofer/metacello to load the version of fuel, iterate over each file and serialize/materialize. > The migration procedure seems safer to me, if it did not load code in the > middle of the process. There's lots of workarounds for this issue, so it's > not a high priority. > > > A separate issue is that at some point I wanted to serialize >> something differently, in two different contexts. In one case, >> serializing a Pier kernel, I want Fuel to just do its thing. In the >> other case, when exporting a portion a Pier kernel, I want to fine >> tune (i.e. map to different objects) the objects being >> exported/imported. There is a hook to allow the object swap, but the >> swap would then take place for the other case of serializing to >> whole kernel (where the desired behaviour was for no such mapping). >> >> >> That's an interesting point....Let me see if I understood. Let's say >> that you want to exclude certain instance variables of a class. What you >> mean is that you want to apply this hook (or another one) in an specific >> serialization and not always? because right now with Fuel (and SIXX, and >> I guess StOMP also) since you put the hooks in methods of the class, >> they are always taken into account. How would the API for the user >> should be? you can you specify for an specific serialization run that >> certain hook of certain object/class must be applied and some should not ? >> > > Yes, you've got the idea. No idea what the API should be for such > functionality - probably a serialization context (passed in at the start) > that answers configuration parameters to use to pick an object mapping > method. Interesting. I will open an issue for this. > > > Apart from that, do you have a real example where you need such behavior >> ? Beause it looks quite complex/rare scenario ;) >> > > My serialization code is not top of mind, but I think the issue I had was > that when exporting a portion of a Pier kernel, for importing into another > Pier kernel, the security objects should be nil'ed out. However, when using > Fuel to serialize the kernel, the security objects must be serialized > instead of being nil'ed out. Well...that can be simple workarrounded with a simple if depending on what you want. So depending what you do, you can serialize or not the security objects. This can be done without needing what you say. It may not be the best solution, but a workarround. > Not sure why I don't currently have a bug - probably, the security is being > inherited from the parent structures when they're nil. I'll see the problem > once I try to set different security on lower down structures - they'll be > lost on restart. > Ok. Check: http://rmod.lille.inria.fr/web/pier/software/Fuel/Hooks http://forum.world.st/Any-serializer-can-customize-serialization-strategy-td3891555.html Cheers > > -- > Yanni > > > -- Mariano http://marianopeck.wordpress.com
