Hi,
I have a Simple class hierarchy: Bank accounts (Collection of: Account). Account SpecialAccountA SpecialAccountB SpecialAccountC. I can store aBank in the database but when I load it from the database this variable (accounts) apperas as DBError. Why ? I suspect because there is not exists anAccount table, the tables are: SpecialAccountA. SpecialAccountB. SpecialAccountC. what i'm doing wrong ? Regards Bruno |
Bruno wrote:
> I have a Simple class hierarchy: > Bank > accounts (Collection of: Account). > Account > SpecialAccountA > SpecialAccountB > SpecialAccountC. > > I can store aBank in the database but when I load it from the database this > variable (accounts) apperas as DBError. > Why ? > I suspect because there is not exists anAccount table, the tables are: > SpecialAccountA. > SpecialAccountB. > SpecialAccountC. > > what i'm doing wrong ? I haven't really used this aspect of ReStore, but I'll take a shot at trying to help you out. In your example, "accounts" as a collection of Accounts will only be able to hold a mix of different subclasses of Account if they all share a common table. Since the default is that a hierarchy of classes will share a single table, I can think of a couple of things that may have changed this. You might have implemented either #shouldSubclassesInheritPersistency or #shouldInheritPersisteny as "^false" which could cause separate tables to be used. The other (more likely cause) is that Account class does not itself define #addClassDefinitionTo:, such that ReStore does not treat Account as a persistent class, only the subclasses. HTH, -Bill ------------------------------------------- Bill Dargel [hidden email] Shoshana Technologies 100 West Joy Road, Ann Arbor, MI 48105 USA |
In reply to this post by Bruno Brasesco
> Bank
> accounts (Collection of: Account). > Account > SpecialAccountA > SpecialAccountB > SpecialAccountC. > > I can store aBank in the database but when I load it from the database this > variable (accounts) apperas as DBError. > Why ? > I suspect because there is not exists anAccount table, the tables are: > SpecialAccountA. > SpecialAccountB. > SpecialAccountC. Two options: 1. Separate accounts in three collections (with three db tables). Bank specialsA Collection of: SpecialAccountA. specialsB Collection of: SpecialAccountB. specialsC Collection of: SpecialAccountC. OR: 2. Share a table (only one db table). Account table store all instances of: SpecialAccountA. SpecialAccountB. SpecialAccountC. Regards Bruno |
In reply to this post by Bill Dargel
> In your example, "accounts" as a collection of Accounts will only be
> able to hold a mix of different subclasses of Account if they all share > a common table. Since the default is that a hierarchy of classes will > share a single table, I can think of a couple of things that may have > changed this. Yes, like you say i'm using a shared table. Regards Bruno |
In reply to this post by Bruno Brasesco
Bruno,
> Two options: > 1. Separate accounts in three collections (with three db tables). > ... > 2. Share a table (only one db table). You're right that Collections in ReStore have to contain objects of the same class, or from the same hierarchy of persistent classes. If you're having problems setting up this latter "shared table" approach, here's some pointers: 1) ensure the subclass (SpecialAccountA etc.) class definition method also adds in the superclass definition, i.e. SpecialAccountA>>addClassDefinitionTo: aClassDef super addClassDefinitionTo: aClassDef. aClassDef define: #... 2) ensure you're adding the superclass and all subclasses to ReStore: aReStore addClassWithSubclasses: Account 3) Not actually related to persistent hierarchies, but I notice in your original post you said 'accounts' was defined as (Collection of: Account) - you actually need to specify a concrete collection class (e.g. OrderedCollection) rather than the abstract Collection class. Hope this helps - if you're still experiencing problems I can mail you an example package. Best regards, John Aspinall Solutions Software |
> 3) Not actually related to persistent hierarchies, but I notice in your
original > post you said 'accounts' was defined as (Collection of: Account) - you actually > need to specify a concrete collection class (e.g. OrderedCollection) rather than > the abstract Collection class. I solve my problem with a shared table. And the collection is actualy anOrderedCollection (my mistake in the mail). Thanks Bruno |
Free forum by Nabble | Edit this page |