Re: Flat File Fun (or You Just Saved My Class)

[Abigail-II]

This is not an easy question to answer. No doubt, you'll see quick posts saying "use Date::Dumper", "use YAML" or some other serialization technique.

But then what. So you decide the pick YAML, what's next? That's the wrong time to start asking questions. First you have to know, what is that data I need to save? Why am I saving? Is it for persistence, that is, do I have to be able to reconstruct the object? It might be that all you need to save is everything reachable from the object ref. But what about class data? Is the class keeping track of the objects? Perhaps it's keeping count of how many objects are out there - perhaps you use fly-weight objects or Inside Out Objects. Then there will be (possible lexical) data in the classes that need to be saved too.

So you first have to determine what you need to save to be able to reconstruct. Determine what kind of relations there are between the pieces of data that need extra attention. For instance, the class puts the various objects of that class in a hash, using the objects as keys. Which means, the keys are the stringified forms of the references. On restoring, you most likely get different addresses for your references, and hence the stringified form is likely to be different. Then your saved class data is useless, and you have a major data corruption.

Having decided what to store, and what meta data to store, then you can focus your attention which technique to use. Not all techniques are perfect. Code references are hard to serialize. Some techniques turn strings into numbers on certain conditions, which can lead to data corruption again. (Numifying and then stringifying "5.000" gives you "5", not "5.000").

So, what the "best way" can't be determined until you have implemented more of it. In fact even the question "what is a correct way" can't be answered yet.

Abigail

[abitkin]

Okay, so here's how the data breaks down:

The idea is the project will be a rideshare program. The idea being that each one of these objects shown will be shown to the user as a unique ID (so that they can do specific actvities.) Each portion of the data structure is built by the user and it needs to persist between runs so that it can continue to be modified. For the scope of this project, I don't need to worry about more than 1 user accessing the program at a time.

One posibility is to just add the unique IDs that I'm giving to the user to the actual objects and ignore inheritance all together; however, doing that would make the implimentation of this system much more difficult. It is true that certian "modes" of this program will not require the whole structure to be rebuilt; however, these repesent the minority of all cases.
==
Kwyjibo. A big, dumb, balding North American ape. With no chin.

[Abigail-II]

Given my previous post, you aren't thinking that I now tell you what to do, just based on two small paragraphs of description, one of which is just exploring a possibility?

Make an implementation, then we'll see.

Abigail

[waswas-fng]

On the other hand he can make the implentation with the stor meathod in mind. Depending on how he implements, his store becomes more or less complicated. What is wrong with him getting options before he implements?

-Waswas