Bob, Having no mapping for the Employee class means the ORM can't hand you a collection of Employees. If you wanted such a beast, you'd need combine the collections of all the subclasses. The common Employee.cfc superclass gives you common instance logic, but not common collection logic.
Another example - I know I have an employee called Bob, how do I load his record as an object? The naive approach is to ask the ORM to load employee where name = Bob. In some ORMs, we can do exactly that. Without a mapped superclass, however, we have to either hand-code a query to hit the employee table, grab an ID and a type, then ask the ORM to load an instance of that type, or iterate over all the subclasses asking the ORM for "Bob" for each of them until we find Bob. None of this is onerous in practice, but it's definitely part of the impedance mismatch. Jaime On Mon, Mar 2, 2009 at 11:24 PM, Bob Silverberg <[email protected]>wrote: > I think that this addresses the issue of behaviour that is common to > all Employees, so I'm not sure what you mean when you say: "but you > then need to hand-code anything that relates to all employees". Could > you elaborate on that? > > Thanks, > Bob > > > --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
