Hi list,
In my work with Glorp I found a problem using polymorphic lists. I will abstract from the actual problem, and use a test app in which it will be shown. I used the technique described in the GlorpTutorial by Roger Whitney. I work with UnitOfWork. I work with Postgresql. The problem I encountered was that the parent id's to be stored in the tables representing the contained objects where not stored. In order to show it I designed a simple system. I have a oneToMany structure with a holder and a polymorphic list of contained objects. In the example AbHolder and the contained types AbSubOne, AbSubTwo and AbSubThree. I can test this with a tester class: AbTesterMulti. In the tester class I first have to drop the existing database schema. Then I can create a new one. Finaly I cann fill the new one with a couple of holder object, each with a couple of sub objects. In this filling testmethod I test whether the total nr of children of holders equals the total nr of AbSub objects (AbSubOne, AbSubTwo, AbSubThree). This is OK, but it is within the same session. Testing in a new session shows part of the problem: after reading the holders they each have all of the sub objects in their list. Looking in the database it shows no foreign keys in the parent fields. Reducing the system to a single sub type (AbSubOne) by defining a new Descriptor system shows that the problems are over when polymorphism is not used. The foreign keys in the database are updated. To experiment and reproduce the problem I add a zipfile with the package. You need to change username and password for database access. You also need to create a test database (here I created the database ab). Reinier van Oosten tel: 0546-623511 gsm: 0651335993 email: [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc Ab domain.st.zip (4K) Download Attachment |
The problem with this is that you've not defined a join for
the #list relationship. That works fine for simple or unambiguous
relationships, Glorp will figure out the join. But it's not smart enough
to figure out a join for a polymorphic relationship, you need to define
it explicitly, and it's fairly messy. See, for example,
descriptorForGlorpWarehouse in the tests. The tutorial really only covers
querying via inheritance, not defining a relationship to an abstract
class, which is unfortunately trickier.
Also, a couple of minor notes on the sample provided. It's probably easier to send messages like recreateTables, dropTables, or createTables to the session rather than duplicating parts of that code. Also, you no longer need to define allTableNames and constructAllClasses for most cases, it'll figure it out from the descriptor, table, classModel methods. One technique that's also useful is to send the message "debugWrite: true" to a mapping. That will halt when it goes to actually write the information and you can get a better handle on what's happening (or not happening). That's probably not as useful when trying to go through the tutorial, but might be handy to know. In this case, seeing that the join was empty might be helpful. At 05:55 AM 2009-12-21, reinier van oosten wrote: Hi list, --
Alan Knight [|], Engineering Manager, Cincom Smalltalk
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Alan,
Thanks a lot for the advise. This really did the trick. I tried it in a new Descriptor system with a new testCase: AbDescriptorPolymorphicSystem and AbTesterPoly. In order to check whether I understood it sufficient for my actual problem I added a new system: AbDescriptorDoubleSystem with tester AbTesterDouble. It has not one, but two oneToMany associations. All subs are meaningfull domain objects. But they are polymorphic. Therefor you can't use a link table. I added it to the package. I send you the zipped package. Again, the username, password and connectstring should be localized. This definition has moved to a single place: AbTesterOne class->definitions. Reinier van Oosten tel: 0546-623511 gsm: 0651335993 email: [hidden email] On Dec 21, 2009, at 6:19 PM, Alan Knight wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc Ab domain.st.zip (5K) Download Attachment |
Free forum by Nabble | Edit this page |