Using BOSS I seem to lose information
Locked
 
|
Admittedly, my BOSS object is rather complex (accounts with transactions, and several thousands of them), but it seems rather odd to me that objects seem to randomly disappear when loading it.
This is what happens. I save my account system as a BOSS file. I read it back in, and suddenly some of the entries in the list, which are the part of the transaction in the account I am viewing (the other part is in the counteraccount) have no counter entries anymore (showing the counteraccount as nil).
What's worse, is that this behaviour occurs without any errors in either saving or loading. That is why it took some days before I noticed it.
I attempted saving with expectCycles on, but that did result in errors.
Also, this "forgetting" of objects seems random, that is the next time I load other counter entries are missing. Is BOSS suffering from age?
Rob Vens
|
Re: Using BOSS I seem to lose information
|
|
I use BOSS as the storage mechanism for BottomFeeder, so I don't think it's
suffering from age. Can you tell us more specifically what doesn't get saved? At 04:44 AM 2/2/2006, you wrote: >Admittedly, my BOSS object is rather complex (accounts with transactions, >and several thousands of them), but it seems rather odd to me that objects >seem to randomly disappear when loading it. >This is what happens. I save my account system as a BOSS file. I read it >back in, and suddenly some of the entries in the list, which are the part >of the transaction in the account I am viewing (the other part is in the >counteraccount) have no counter entries anymore (showing the >counteraccount as nil). >What's worse, is that this behaviour occurs without any errors in either >saving or loading. That is why it took some days before I noticed it. >I attempted saving with expectCycles on, but that did result in errors. >Also, this "forgetting" of objects seems random, that is the next time I >load other counter entries are missing. Is BOSS suffering from age? > >Rob Vens |
|
|
The object I want to save to BOSS was until recently saved and re-created from a parcel. Problems with packaging using parcels led me to trying BOSS (as I have often done in the past).
It is an account system with accounts. Income statement accounts and balance sheet accounts. The balance sheet accounts are shown in the application. All entries in the balance sheet accounts are one leg of a two legged transaction, with the other leg in an income statement account or in a balance sheet account (which is called a transfer).
Now what happens is I load a BOSS file (which has been saved without reporting any errors) and it loads perfectly. I open an account, and I see the list of transactions in a data set view. I click on a row and a walkback appears, effectively telling me that dynamically updating the list view's popup menu encountered a situation that should not occur, namely that enumerating the entries in the list it encountered entries without an other leg, that is the counter entry is nil. Using the debugger I can get the culprit, confirming the malformed object.
The next time I open the application other entries in the account than in the previous run suffer from this disability, so it seems random...
The two legs of the transaction are part of a transaction object, and it seems that the one transaction object gets broken up into two disconnected transaction, each with one entry only. I checked one entry for example, in the balance sheet account. It was part of a transaction, but the other leg was nil. The other leg, as an entry in a different transaction object however, was found in the proper income statement account, but again in a transaction with only this entry and the counterentry nil.
Mind you: this occurs for, say 20 entries in a list of hundreds. So not all entries and transactions are involved. Also the accounts involved differ.
I have no overridden representBinaryOn: methods yet in any of the classes involved, it was just a first cut at moving from parcel to BOSS.
I have no idea where to start looking for the cause of the problem.
2006/2/2, James Robertson <[hidden email]>:
I use BOSS as the storage mechanism for BottomFeeder, so I don't think it's |
Re: Using BOSS I seem to lose information
|
|
I think you're going to have to do a save, leaving the application open,
then boss the data in, and see if you can spot the discrepancies At 02:05 PM 2/2/2006, you wrote: >The object I want to save to BOSS was until recently saved and re-created >from a parcel. Problems with packaging using parcels led me to trying BOSS >(as I have often done in the past). >It is an account system with accounts. Income statement accounts and >balance sheet accounts. The balance sheet accounts are shown in the >application. All entries in the balance sheet accounts are one leg of a >two legged transaction, with the other leg in an income statement account >or in a balance sheet account (which is called a transfer). >Now what happens is I load a BOSS file (which has been saved without >reporting any errors) and it loads perfectly. I open an account, and I see >the list of transactions in a data set view. I click on a row and a >walkback appears, effectively telling me that dynamically updating the >list view's popup menu encountered a situation that should not occur, >namely that enumerating the entries in the list it encountered entries >without an other leg, that is the counter entry is nil. Using the debugger >I can get the culprit, confirming the malformed object. >The next time I open the application other entries in the account than in >the previous run suffer from this disability, so it seems random... >The two legs of the transaction are part of a transaction object, and it >seems that the one transaction object gets broken up into two disconnected >transaction, each with one entry only. I checked one entry for example, in >the balance sheet account. It was part of a transaction, but the other leg >was nil. The other leg, as an entry in a different transaction object >however, was found in the proper income statement account, but again in a >transaction with only this entry and the counterentry nil. >Mind you: this occurs for, say 20 entries in a list of hundreds. So not >all entries and transactions are involved. Also the accounts involved differ. >I have no overridden representBinaryOn: methods yet in any of the classes >involved, it was just a first cut at moving from parcel to BOSS. >I have no idea where to start looking for the cause of the problem. > >2006/2/2, James Robertson <<mailto:[hidden email]>[hidden email]>: >I use BOSS as the storage mechanism for BottomFeeder, so I don't think it's >suffering from age. Can you tell us more specifically what doesn't get >saved? > >At 04:44 AM 2/2/2006, you wrote: > >Admittedly, my BOSS object is rather complex (accounts with transactions, > >and several thousands of them), but it seems rather odd to me that objects > >seem to randomly disappear when loading it. > >This is what happens. I save my account system as a BOSS file. I read it > >back in, and suddenly some of the entries in the list, which are the part > >of the transaction in the account I am viewing (the other part is in the > >counteraccount) have no counter entries anymore (showing the > >counteraccount as nil). > >What's worse, is that this behaviour occurs without any errors in either > >saving or loading. That is why it took some days before I noticed it. > >I attempted saving with expectCycles on, but that did result in errors. > >Also, this "forgetting" of objects seems random, that is the next time I > >load other counter entries are missing. Is BOSS suffering from age? > > > >Rob Vens > |
|
|
Most peculiar indeed! Here's what I did: open the app, load the domain from a parcel. Everything ok. Save to boss. Check: everything's fine. Open the boss file: everything's fine still! Save again to boss. Open the boss file: oops, now we're in trouble. This seems very weird to me.
2006/2/2, James Robertson <[hidden email]>:
I think you're going to have to do a save, leaving the application open, |
RE: Using BOSS I seem to lose information
|
|
In reply to this post by Rob Vens
Having things work
OK in memory, then lose some entries when serialised and deserialised, with the
missing entries being different each time, sounds like what happens with some
hashing problems. Is that possible for your data? Is the counter variable's
contents the other object itself, or some string or number which is looked up
somewhere to return the other leg?
If debugging isn't making any sense, maybe you could
try cutting down the number of different classes you save, and the number of
instance variables in each, to get a minimal(ish) reproducable test case.
Our OO database is based on BOSS, and we've not
had any problems with losing data (files have up to 100MB, although normally
around 5MB). Our experience is mostly in VW 2.0, 3.0, 7.1 and 7.3.1, with some
on the versions between.
Good
luck!
Steve
|
|
|
To answer some of your questions: the other leg is an object, not a string lookup or something.
Your hash remark was something I thought of too, and made me check whether I overruled = and hash in one of my classes. It appeared I did, in three classes involved in this: a Currency class, a CurrencyUnit class, and a PartyName class. Not in the Entry or Transaction classes however. Maybe I'll change the hash implementation in these classes and see what happens.
Debugging isn't making any sense, at least I wouldn't know where to begin. Creating a minimal reproducable test case is not easy either I guess but I'll try if I can find the time. This issue is demotivating me right now I'm afraid, this is what happens if you work on a project in your "free" time...
Thank so far!
2006/2/2, Steven Kelly <[hidden email]>:
|
Re: Using BOSS I seem to lose information
|
|
I wonder if it would not be a more satisfying experience to just use
something like OmniBase at your persistence layer. That way instead of spending time debugging just to get back up and running you will have spent time integrating a more robust and used framework than your home grown one i.e. it would add value to your product and it should feel that you have advanced in your efforts. I have used Boss pretty heavily since 94. I don't recall losing data. I guess it is possible that something was introduced but I doubt it. -Charles On Thu, 02 Feb 2006 15:36:53 -0500, Rob Vens <[hidden email]> wrote: > To answer some of your questions: the other leg is an object, not a > string > lookup or something. > Your hash remark was something I thought of too, and made me check > whether I > overruled = and hash in one of my classes. It appeared I did, in three > classes involved in this: a Currency class, a CurrencyUnit class, and a > PartyName class. Not in the Entry or Transaction classes however. Maybe > I'll > change the hash implementation in these classes and see what happens. > Debugging isn't making any sense, at least I wouldn't know where to > begin. > Creating a minimal reproducable test case is not easy either I guess but > I'll try if I can find the time. This issue is demotivating me right now > I'm > afraid, this is what happens if you work on a project in your "free" > time... > Thank so far! > > > 2006/2/2, Steven Kelly <[hidden email]>: >> >> Having things work OK in memory, then lose some entries when serialised >> and deserialised, with the missing entries being different each time, >> sounds >> like what happens with some hashing problems. Is that possible for your >> data? Is the counter variable's contents the other object itself, or >> some >> string or number which is looked up somewhere to return the other leg? >> >> If debugging isn't making any sense, maybe you could try cutting down >> the >> number of different classes you save, and the number of instance >> variables >> in each, to get a minimal(ish) reproducable test case. >> >> Our OO database is based on BOSS, and we've not had any problems with >> losing data (files have up to 100MB, although normally around 5MB). Our >> experience is mostly in VW 2.0, 3.0, 7.1 and 7.3.1, with some on the >> versions between. >> >> Good luck! >> Steve >> >> -----Original Message----- >> *From:* Rob Vens [mailto:[hidden email]] >> *Sent:* 02 February 2006 21:06 >> *To:* James Robertson >> *Cc:* [hidden email] >> *Subject:* Re: Using BOSS I seem to lose information >> >> The object I want to save to BOSS was until recently saved and >> re-created >> from a parcel. Problems with packaging using parcels led me to trying >> BOSS >> (as I have often done in the past). >> It is an account system with accounts. Income statement accounts and >> balance sheet accounts. The balance sheet accounts are shown in the >> application. All entries in the balance sheet accounts are one leg of a >> two >> legged transaction, with the other leg in an income statement account >> or in >> a balance sheet account (which is called a transfer). >> Now what happens is I load a BOSS file (which has been saved without >> reporting any errors) and it loads perfectly. I open an account, and I >> see >> the list of transactions in a data set view. I click on a row and a >> walkback >> appears, effectively telling me that dynamically updating the list >> view's >> popup menu encountered a situation that should not occur, namely that >> enumerating the entries in the list it encountered entries without an >> other >> leg, that is the counter entry is nil. Using the debugger I can get the >> culprit, confirming the malformed object. >> The next time I open the application other entries in the account than >> in the previous run suffer from this disability, so it seems random... >> The two legs of the transaction are part of a transaction object, and it >> seems that the one transaction object gets broken up into two >> disconnected >> transaction, each with one entry only. I checked one entry for example, >> in >> the balance sheet account. It was part of a transaction, but the other >> leg >> was nil. The other leg, as an entry in a different transaction object >> however, was found in the proper income statement account, but again in >> a >> transaction with only this entry and the counterentry nil. >> Mind you: this occurs for, say 20 entries in a list of hundreds. So not >> all entries and transactions are involved. Also the accounts involved >> differ. >> I have no overridden representBinaryOn: methods yet in any of the >> classes >> involved, it was just a first cut at moving from parcel to BOSS. >> I have no idea where to start looking for the cause of the problem. >> >> 2006/2/2, James Robertson <[hidden email]>: >> > >> > I use BOSS as the storage mechanism for BottomFeeder, so I don't think >> > it's >> > suffering from age. Can you tell us more specifically what doesn't >> get >> > saved? >> > >> > At 04:44 AM 2/2/2006, you wrote: >> > >Admittedly, my BOSS object is rather complex (accounts with >> > transactions, >> > >and several thousands of them), but it seems rather odd to me that >> > objects >> > >seem to randomly disappear when loading it. >> > >This is what happens. I save my account system as a BOSS file. I read >> > it >> > >back in, and suddenly some of the entries in the list, which are the >> > part >> > >of the transaction in the account I am viewing (the other part is in >> > the >> > >counteraccount) have no counter entries anymore (showing the >> > >counteraccount as nil). >> > >What's worse, is that this behaviour occurs without any errors in >> > either >> > >saving or loading. That is why it took some days before I noticed it. >> > >I attempted saving with expectCycles on, but that did result in >> errors. >> > >Also, this "forgetting" of objects seems random, that is the next >> time >> > I >> > >load other counter entries are missing. Is BOSS suffering from age? >> > > >> > >Rob Vens >> > >> > >> -- Charles A. Monteiro |
RE: Using BOSS I seem to lose information
|
|
In reply to this post by Rob Vens
Hi Rob, I too have been using BOSS as a home grown
persistence mechanism. The main difficulty I’ve had is isolating the specific
cluster of objects I wish to persist, so that one doesn’t end up sucking
the whole domain in or hooking into un-BOSSable
objects. To do this I create a copy of the cluster, breaking links at the
appropriate places. This makes me think that maybe it’s
not the reading of the structure that’s the problem, but that maybe you
are have inadvertently created a copy of your Transaction object sometime
before you serialise your structure. To check this you could hack the BOSSWriter>>trace: method. Another possibility is to use the BOSSDebugReader, or hack BOSSReader
to see what is going on as the objects are deserialised. I can understand most areas of VisualWorks when reading the code, but this area I treat as
a wonderful “BlackBox” that works and has
stood the test of time. Only to be delved into when I have problems such as
yours! Good luck, Stewart PS I’m curious as to the development
history of this subsystem if anybody knows… -----Original Message----- Most peculiar indeed!
Here's what I did: open the app, load the domain from a parcel. Everything ok.
Save to boss. Check: everything's fine. Open the boss file: everything's fine
still! Save again to boss. Open the boss file: oops, now we're in trouble. This
seems very weird to me. 2006/2/2, James Robertson <[hidden email]>: I think you're going to
have to do a save, leaving the application open, |
|
|
Thank you Stewart,
Indeed, for many years I also used "copy" as the trick to avoid BOSS-ing transient objects like Windows etc. or other objects I do not want to take along. So I already have checked all implementors of copy in my objects to see if something like that occurs. I have not overridden copy however in any of my domain classes. I ***want*** the entire domain to persist as a whole.
But your suggestion of tracing the BOSSWriter is a good one. I will need to write a minimal reproducable test case first because my current domain is quite huge.
2006/2/9, Stewart MacLean <[hidden email]>:
|
| Free forum by Nabble | Edit this page |