Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi there, On 01/06/2007, at 10:50 PM, Craig L Russell wrote: On Jun 1, 2007, at 2:42 AM, Andrus Adamchik wrote: On May 31, 2007, at 9:51 AM, Lachlan Deck wrote: There are numerous uses for these partial instances (if you'd like to call them that) when you want to only fetch the characteristics of the parent, for example, without also having to fault in the data for the subclasses. e.g., if I have a service thread that once every 10 minutes or so polls a message- queue to send a message to a list of recipients the only data I'm interested in fetching in is that of the parent entity. I still have trouble with this. If this is a requirement, I'd suggest mapping the superclass independently, that is using a completely different class. The question in the end is whether the tool/framework enforces what in the end (as it seems to me) comes down to an object design decision of which there are always various forks in the road as it can depend on the needs of the individual application (which we all know in reality can change/grow at any particular point in time throughout the life of an application). e.g., such design decisions cannot always be imposed upon legacy systems. I'm simply suggesting that Cayenne (and any other ORM for that matter) can quite simply allow for either case. To do so is at the end-user's risk. Then you can have part of your application that doesn't care about the subclass part at all. That certainly is a risk that is worth documenting for an end- developer but I don't believe should be enforced by the framework. In most situations (that I can envisage anyway) the use-case for instantiating a parent entity (rather than the sub-entity to which it belongs) would be in a read-only mode. But again that's application specific. It would still be a very bad choice if you were to mix the model containing the full inheritance relationship and the partial mapping, because you would potentially have conflicting updates of the same data. I'm not sure how that would be different from current update conflicts. Perhaps that would depend upon the locking behaviour (optimistic etc). But you would be avoiding the complexity and the usability issues associated with having an instance that was mapped as a subclass yet in memory had no subclass behavior. Are there any particular complexities you have in mind? For mine, any such complexity would be introduced by an individual developer, I believe, in edge-cases where for some strange reason the developer decides to modify the parent record (e.g., incrementing some dateOfLastAccess field). I suppose I keep coming back to this question: 'why should the framework impose an ideal restriction when there are in reality business cases for doing otherwise?' i.e., If allowing the parent record to be fetched on its own without needing to additionally fetch the sub-type characteristics allows for certain performance benefits, for example, or otherwise then for mine: +1. Some other developer may have some other needs for which these flexibilities finds a home. All in all my persuasion is that best-practices (for hazy areas like this) are best aimed at documentatation/white-papers. The only complexity I can envision (at this stage - perhaps Andrus would have a better idea) is dealing with the global ids for two objects in memory that for all intents and purpose are the same object, each of which are in separate contexts but where one was fetched as the superclass rather than the subclass it was originally created as. But other than that the normal rules would apply - i.e., where the mapped entity that the parent object corresponds to is the parent entity that just happens to also have a sub-entity. I'm not certain at this stage how the object graph would track these. But it doesn't seem to be something that's conceptually difficult. This is not breaking any inheritance rules even in Java as I see it. It is after all possible in Java itself to have a non- abstract superclass. Whether this leads to a broken mapping or otherwise I don't believe should be a restriction enforced by the tool... but certainly you might like to document the advantages/ disadvantages of such an approach. Hmm... Thinking about it from different angles, I tend to agree with Lachlan. A user can bend the rules with a shallow fetch on a non-abstract superclass, as long as (s)he understands that this (a) breaks uniquing and (b) deleting or inserting such records is asking for trouble. Still IMO, this is not related to the delete rule discussion. An implied CASCADE is the right thing. Andrus with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On Jun 1, 2007, at 2:42 AM, Andrus Adamchik wrote: On May 31, 2007, at 9:51 AM, Lachlan Deck wrote: There are numerous uses for these partial instances (if you'd like to call them that) when you want to only fetch the characteristics of the parent, for example, without also having to fault in the data for the subclasses. e.g., if I have a service thread that once every 10 minutes or so polls a message-queue to send a message to a list of recipients the only data I'm interested in fetching in is that of the parent entity. I still have trouble with this. If this is a requirement, I'd suggest mapping the superclass independently, that is using a completely different class. Then you can have part of your application that doesn't care about the subclass part at all. It would still be a very bad choice if you were to mix the model containing the full inheritance relationship and the partial mapping, because you would potentially have conflicting updates of the same data. But you would be avoiding the complexity and the usability issues associated with having an instance that was mapped as a subclass yet in memory had no subclass behavior. Craig This is not breaking any inheritance rules even in Java as I see it. It is after all possible in Java itself to have a non-abstract superclass. Whether this leads to a broken mapping or otherwise I don't believe should be a restriction enforced by the tool... but certainly you might like to document the advantages/disadvantages of such an approach. Hmm... Thinking about it from different angles, I tend to agree with Lachlan. A user can bend the rules with a shallow fetch on a non-abstract superclass, as long as (s)he understands that this (a) breaks uniquing and (b) deleting or inserting such records is asking for trouble. Still IMO, this is not related to the delete rule discussion. An implied CASCADE is the right thing. Andrus Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 01/06/2007, at 6:55 PM, Andrus Adamchik wrote: IMO, "abstract" is limited to its Java definition, and is of no consequence to the runtime inheritance processing (note that 'resolvingInherited' query property is true by default). I was thinking that 'isAbstract' (if true for the parent entity) might have the effect of implying that any attempt at setting 'resolvingInherited' to false for a query would have no effect as it would be impossible to fulfil such a requirement in the query. Perhaps that's a more tolerant approach(?) than allowing the query to proceed but throwing an exception when attempting to instantiate the abstract parent. But then again I suppose this would train people quickly: 'don't do that!' ;-) So the most important aspect of it is generating a corresponding Java class with an "abstract" keyword, so that Java could throw on any attempts to instantiate it. Sure. with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On May 31, 2007, at 9:51 AM, Lachlan Deck wrote: There are numerous uses for these partial instances (if you'd like to call them that) when you want to only fetch the characteristics of the parent, for example, without also having to fault in the data for the subclasses. e.g., if I have a service thread that once every 10 minutes or so polls a message-queue to send a message to a list of recipients the only data I'm interested in fetching in is that of the parent entity. This is not breaking any inheritance rules even in Java as I see it. It is after all possible in Java itself to have a non-abstract superclass. Whether this leads to a broken mapping or otherwise I don't believe should be a restriction enforced by the tool... but certainly you might like to document the advantages/disadvantages of such an approach. Hmm... Thinking about it from different angles, I tend to agree with Lachlan. A user can bend the rules with a shallow fetch on a non- abstract superclass, as long as (s)he understands that this (a) breaks uniquing and (b) deleting or inserting such records is asking for trouble. Still IMO, this is not related to the delete rule discussion. An implied CASCADE is the right thing. Andrus
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi, Per http://cayenne.apache.org/mailing-lists.html the right email address is "[EMAIL PROTECTED]". Let me know if this still didn't work, and I'll unsubscribe you manually. Andrus On May 31, 2007, at 8:44 AM, srinivas sagar wrote: I have tried to unsubscribe from this list by sending an email to [EMAIL PROTECTED] , but to no avail can anybody suggest how else I could try ?
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
IMO, "abstract" is limited to its Java definition, and is of no consequence to the runtime inheritance processing (note that 'resolvingInherited' query property is true by default). So the most important aspect of it is generating a corresponding Java class with an "abstract" keyword, so that Java could throw on any attempts to instantiate it. Andrus On May 31, 2007, at 3:32 AM, Aristedes Maniatis wrote: On 31/05/2007, at 2:40 AM, Kevin Menard wrote: I'm clearly showing my ignorance on the matter here, but what does it mean for an object to know that it's abstract? Isn't that a property of the class? What happens when you subclass the ObjEntity? Cayenne will need to know this information. For instance, you might have inheritance with an abstract superclass Person. Then performing a query on that class, Cayenne will need to automatically return objects of Student and Tutor subclasses and not the Person superclass. Effectively the flag "setResolvingInherited" will be switched on automatically. If nothing else, this information needs to be stored in the Datamap and the logical place is in the ObjEntity itself. When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. Ari Maniatis --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Craig, On 31/05/2007, at 11:46 PM, Craig L Russell wrote: On May 31, 2007, at 12:21 AM, Aristedes Maniatis wrote: On 31/05/2007, at 4:59 PM, Craig L Russell wrote: If it really is an inheritance relationship and not a one-one or one-many relationship, the compound primary keys should also correspond exactly. Then you are suggesting that we use the name of the attribute in the two ObjEntities as the mechanism to see which pairs correspond. No, I'm suggesting to look at the database schema to find the cases of foreign key == primary key. Good point. I think that's exactly what we've been suggesting (for vertical inheritance) except that such constraints are not necessarily always within the RDBMS but within the Cayenne model. And I don't think there is any need for two different fields to represent the columns in the database that because of foreign key constraints will always contain identical values. Perhaps that assumes that there are indeed such constraints in the database (which is not always the case). You'd naturally hope for that to be the case in normal circumstances but it's also possible to impose in-memory constraints within Cayenne, EOF, or (I assume) any other ORM system. My point is only that the names should not be special, particularly when a user might be refactoring an existing database scheme. Say the user has: Student.studentKey and Tutor.tutorKey as the PK attributes for their existing project. (Not the way I'd do it, but...) Now they want to add Person as a superclass. You are saying this should not be allowed without renaming the existing attributes? I'm a bit unclear what this scenario means. If they want to add Person as a superclass, I would say they need to remap the classes so that the field in the superclass Person corresponding to the primary key columns is the identity field and there is no longer any identity field in the subclasses. Ahh, I think I see where we're coming at this differently (maybe, correct me if I've misunderstood you :-). The only place where the primary/foreign keys are defined (or remapped) with Cayenne (or EOF for that matter) are within the model; not within the java classes as they are deemed database artefacts that the user is unaware of in normal circumstances. There is nothing in code (unless you choose to expose the primary/foreign key(s) as class attributes) that tells the programmer what the name of the primary key is. It's usually irrelevant. Thus the normal rules of inheritance-within-java is a different scenario where it is indeed impossible to change the signature of an inherited attribute/method. Here, there is no signature to change - they're only known to the Cayenne runtime as defined in the model. Within the modelling environment we're essentially creating "is-a" relationships. So the question being discussed here is how is that relationship defined? The answer to that question depends upon the type of inheritance chosen. For vertical (or Inheritance.JOINED), for example, at runtime I'm envisaging (based upon EOF experience) that Cayenne would propagate a primary key value from the super-class table to the subclass table when inserting a new record (seeing as the next primary key value is a function of the parent table [or some other table that's keeping tabs]). Also, as Lachlan points out, this means that we don't get to specific nullify, cascade, etc delete rules. If you have a concrete superclass, you may wish to nullify the relationship when deleting the subclass record. Naturally if the superclass is abstract this is not allowed. But specifying the objrelationship explicitly allows us to put these rules somewhere and remove any ambiguity from compound key relationships. This seems like an implementation detail (which I am very obviously not competent to comment on). Well, it is a functionality decision. Do we want users to be able to delete the subclass without deleting the superclass? If this is a requirement, I'd recommend against mapping this schema as inheritance. I'd map it as a one-to-zero-or-one relationship. Then it's easy to delete the "subclass" instance while leaving the "superclass" instance intact. Sure, something like a Role-based mapping might be a good choice or whatever. Here's a bad example of a situation where the parent record may not want to be deleted along with the sub-entity. Person -->> EmployeeRole ^ | is-a -- Client I'm suggesting that the tool that generates the Java model from the database schema should be configurable to recognize the specific pattern of table2 having a primary key == foreign key to table1 and generate an inheritance relationship of class2 extends class1. I suspect we might be coming at this from different angles. I'm coming from the angle of modelling your object hierarchy to a schema (whether it exists or not) vs the other way
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Ari, On May 31, 2007, at 12:21 AM, Aristedes Maniatis wrote: On 31/05/2007, at 4:59 PM, Craig L Russell wrote: If it really is an inheritance relationship and not a one-one or one-many relationship, the compound primary keys should also correspond exactly. Then you are suggesting that we use the name of the attribute in the two ObjEntities as the mechanism to see which pairs correspond. No, I'm suggesting to look at the database schema to find the cases of foreign key == primary key. And I don't think there is any need for two different fields to represent the columns in the database that because of foreign key constraints will always contain identical values. My point is only that the names should not be special, particularly when a user might be refactoring an existing database scheme. Say the user has: Student.studentKey and Tutor.tutorKey as the PK attributes for their existing project. (Not the way I'd do it, but...) Now they want to add Person as a superclass. You are saying this should not be allowed without renaming the existing attributes? I'm a bit unclear what this scenario means. If they want to add Person as a superclass, I would say they need to remap the classes so that the field in the superclass Person corresponding to the primary key columns is the identity field and there is no longer any identity field in the subclasses. Also, as Lachlan points out, this means that we don't get to specific nullify, cascade, etc delete rules. If you have a concrete superclass, you may wish to nullify the relationship when deleting the subclass record. Naturally if the superclass is abstract this is not allowed. But specifying the objrelationship explicitly allows us to put these rules somewhere and remove any ambiguity from compound key relationships. This seems like an implementation detail (which I am very obviously not competent to comment on). Well, it is a functionality decision. Do we want users to be able to delete the subclass without deleting the superclass? If this is a requirement, I'd recommend against mapping this schema as inheritance. I'd map it as a one-to-zero-or-one relationship. Then it's easy to delete the "subclass" instance while leaving the "superclass" instance intact. If the superclass is concrete why not allow that to happen? And in that case, we need to store the relationship attributes somewhere. Thankfully, we already have a mechanism to do this. I'm not 100% clear on what you are proposing. Is it that Cayenne should be able to construct the appropriate JOIN by looking just at the PK flag s on the attributes in question, without needing any other information stored in XML in the model? If so, why is that better than storing the (possibly redundant, but not always) information in the XML datamap file? I'm suggesting that the tool that generates the Java model from the database schema should be configurable to recognize the specific pattern of table2 having a primary key == foreign key to table1 and generate an inheritance relationship of class2 extends class1. If the requirement is to be able to independently manage instances of class1 and class2, then the tool should be able to map this pattern as a one- to-zero-or-one relationship. And just so it's clear, I'm not an expert in Cayenne [or EOF]. I'm only offering suggestions based on a few years of doing enterprise ORM. And the closer you are to being concept-compliant with JPA and JDO, the more your users will be able to use other standards. Reusable programmers is still a viable objective. Craig Ari Maniatis --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 4:59 PM, Craig L Russell wrote: If it really is an inheritance relationship and not a one-one or one-many relationship, the compound primary keys should also correspond exactly. Then you are suggesting that we use the name of the attribute in the two ObjEntities as the mechanism to see which pairs correspond. My point is only that the names should not be special, particularly when a user might be refactoring an existing database scheme. Say the user has: Student.studentKey and Tutor.tutorKey as the PK attributes for their existing project. (Not the way I'd do it, but...) Now they want to add Person as a superclass. You are saying this should not be allowed without renaming the existing attributes? Also, as Lachlan points out, this means that we don't get to specific nullify, cascade, etc delete rules. If you have a concrete superclass, you may wish to nullify the relationship when deleting the subclass record. Naturally if the superclass is abstract this is not allowed. But specifying the objrelationship explicitly allows us to put these rules somewhere and remove any ambiguity from compound key relationships. This seems like an implementation detail (which I am very obviously not competent to comment on). Well, it is a functionality decision. Do we want users to be able to delete the subclass without deleting the superclass? If the superclass is concrete why not allow that to happen? And in that case, we need to store the relationship attributes somewhere. Thankfully, we already have a mechanism to do this. I'm not 100% clear on what you are proposing. Is it that Cayenne should be able to construct the appropriate JOIN by looking just at the PK flag s on the attributes in question, without needing any other information stored in XML in the model? If so, why is that better than storing the (possibly redundant, but not always) information in the XML datamap file? Ari Maniatis --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 PGP.sig Description: This is a digitally signed message part
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Aristedes, On May 30, 2007, at 10:09 PM, Aristedes Maniatis wrote: On 31/05/2007, at 1:03 PM, Craig L Russell wrote: While it might be possible theoretically to define a different column in the database to be used as the association column to join rows of a subclass and a superclass table, by far the most common and most understandable way to map inheritance is to simply assume that the primary key of both tables is the same and that the id field in the class contains the value to be used for both primary keys. The direction of the foreign key constraint should indicate which is the subclass. Yes, 99% of the time this is correct. However, if we want to support compound primary keys there is a need to describe how the columns in the subclass map to the columns in the superclass. If it really is an inheritance relationship and not a one-one or one- many relationship, the compound primary keys should also correspond exactly. That way Cayenne can populate them both correctly. Our original plan was to use an object relationship description in the DataMap to describe this pairing. The alternative is to use the names of the object attributes in order to match the primary key columns to each other, but something about this bothers me as an approach. The most common case I've seen has a foreign key constraint defined on the primary key columns of the subclass table to the corresponding primary key columns of the superclass table. Also, as Lachlan points out, this means that we don't get to specific nullify, cascade, etc delete rules. If you have a concrete superclass, you may wish to nullify the relationship when deleting the subclass record. Naturally if the superclass is abstract this is not allowed. But specifying the objrelationship explicitly allows us to put these rules somewhere and remove any ambiguity from compound key relationships. This seems like an implementation detail (which I am very obviously not competent to comment on). Regards, Craig Ari --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi again, On 31/05/2007, at 4:32 PM, Craig L Russell wrote: On May 30, 2007, at 11:19 PM, Lachlan Deck wrote: On 31/05/2007, at 4:13 PM, Craig L Russell wrote: On May 30, 2007, at 8:19 PM, Lachlan Deck wrote: However, my question remains this: if not defined in a relationship where does the developer define the delete rules etc? Or are you suggesting they don't get an option? In an inheritance situation, there is only one instance corresponding to the rows (one row in each table in the hierarchy). I'm suggesting that there is no option. If the instance is deleted, then the row in each table is deleted. That's fine when the parent is abstract (i.e., not instantiatable). What about when the parent is not abstract and where it is thus possible to simply fetch/instantiate the parent entity on its own. What happens when the user deletes the parent object in such a situation? Should I not get the choice? I don't believe that you should be able to fetch the parent entity on its own. IMHO If you allow the parent entity to be fetched and don't also fetch the data from the subclass then you have a broken mapping. The user should not be allowed to get a partial instance (data from the parent table only) because then the whole Java concept of subclasses overriding behavior doesn't work any more. There are numerous uses for these partial instances (if you'd like to call them that) when you want to only fetch the characteristics of the parent, for example, without also having to fault in the data for the subclasses. e.g., if I have a service thread that once every 10 minutes or so polls a message-queue to send a message to a list of recipients the only data I'm interested in fetching in is that of the parent entity. This is not breaking any inheritance rules even in Java as I see it. It is after all possible in Java itself to have a non-abstract superclass. Whether this leads to a broken mapping or otherwise I don't believe should be a restriction enforced by the tool... but certainly you might like to document the advantages/disadvantages of such an approach. If it's of any help these concepts have been around for a while (http://developer.apple.com/documentation/WebObjects/UsingEOModeler/ index.html). with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Lachlan, On May 30, 2007, at 11:19 PM, Lachlan Deck wrote: Hi Craig, On 31/05/2007, at 4:13 PM, Craig L Russell wrote: On May 30, 2007, at 8:19 PM, Lachlan Deck wrote: However, my question remains this: if not defined in a relationship where does the developer define the delete rules etc? Or are you suggesting they don't get an option? In an inheritance situation, there is only one instance corresponding to the rows (one row in each table in the hierarchy). I'm suggesting that there is no option. If the instance is deleted, then the row in each table is deleted. That's fine when the parent is abstract (i.e., not instantiatable). What about when the parent is not abstract and where it is thus possible to simply fetch/instantiate the parent entity on its own. What happens when the user deletes the parent object in such a situation? Should I not get the choice? I don't believe that you should be able to fetch the parent entity on its own. IMHO If you allow the parent entity to be fetched and don't also fetch the data from the subclass then you have a broken mapping. The user should not be allowed to get a partial instance (data from the parent table only) because then the whole Java concept of subclasses overriding behavior doesn't work any more. Craig with regards, -- Lachlan Deck Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Craig, On 31/05/2007, at 4:13 PM, Craig L Russell wrote: On May 30, 2007, at 8:19 PM, Lachlan Deck wrote: However, my question remains this: if not defined in a relationship where does the developer define the delete rules etc? Or are you suggesting they don't get an option? In an inheritance situation, there is only one instance corresponding to the rows (one row in each table in the hierarchy). I'm suggesting that there is no option. If the instance is deleted, then the row in each table is deleted. That's fine when the parent is abstract (i.e., not instantiatable). What about when the parent is not abstract and where it is thus possible to simply fetch/instantiate the parent entity on its own. What happens when the user deletes the parent object in such a situation? Should I not get the choice? with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Lachlan, On May 30, 2007, at 8:19 PM, Lachlan Deck wrote: Hi there, On 31/05/2007, at 1:03 PM, Craig L Russell wrote: On May 30, 2007, at 7:23 PM, Lachlan Deck wrote: On 31/05/2007, at 11:54 AM, Lachlan Deck wrote: On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote: On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single- table is well-defined. <...> Okay, so consider the request for superRelationship dropped. (See disclaimer :-) Well that makes it simpler to do all of this ;-) Hang on... Hibernate, for example, does indeed utilise a relationship, to my understanding [1], that specifies the nature of the relationship to the parent, what happens when an object is deleted and so on. These are characteristics that are encapsulated in a relationship. This is why the request for defining a superRelationship in ObjEntity was first made. Perhaps it's an optional for vertical where in its absence is some implicit strategy. Thoughts? The example below shows in Hibernate how to remove the automatically generated relationship between Person and Employee due to the need to map the primary key association to inheritance. I'd even call this a deficiency in the tool, since there is a foreign key constraint defined on the primary key column of the employees table that refers to the primary key column of the persons table. The most natural mapping of this would be inheritance and should therefore be the default. While it might be possible theoretically to define a different column in the database to be used as the association column to join rows of a subclass and a superclass table, by far the most common and most understandable way to map inheritance is to simply assume that the primary key of both tables is the same and that the id field in the class contains the value to be used for both primary keys. The direction of the foreign key constraint should indicate which is the subclass. Sure. (talking from EOF experience again...) the EOF docs for vertical talked about the need for creating a relationship for the case where the tables already exist (and thus their names, for example, may differ) and you're wanting to introduce inheritance (though in practice it needed the relationship either way but that's irrelevant here). Well, from the database perspective there is a difference based on the direction of the foreign key. In general, a subclass table contains the foreign key constraint. There might be several subclass tables, all of which have foreign key constraints on the primary key column of the superclass table. The specific case where there is always a row in each of the tables simply means that there are no other subclasses involved. And in fact, many ORM solutions offer a special case mapping for this, that doesn't involve relationships at all. However, my question remains this: if not defined in a relationship where does the developer define the delete rules etc? Or are you suggesting they don't get an option? In an inheritance situation, there is only one instance corresponding to the rows (one row in each table in the hierarchy). I'm suggesting that there is no option. If the instance is deleted, then the row in each table is deleted. Craig with regards, -- Lachlan Deck Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 3:44 PM, srinivas sagar wrote: I have tried to unsubscribe from this list by sending an email to [EMAIL PROTECTED] , but to no avail can anybody suggest how else I could try ? http://cayenne.apache.org/mailing-lists.html --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 PGP.sig Description: This is a digitally signed message part
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 3:44 PM, srinivas sagar wrote: I have tried to unsubscribe from this list by sending an email to [EMAIL PROTECTED] , but to no avail can anybody suggest how else I could try ? How about reading here: http://cayenne.apache.org/mailing-lists.html with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
I have tried to unsubscribe from this list by sending an email to [EMAIL PROTECTED] , but to no avail can anybody suggest how else I could try ? Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545469
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 1:03 PM, Craig L Russell wrote: While it might be possible theoretically to define a different column in the database to be used as the association column to join rows of a subclass and a superclass table, by far the most common and most understandable way to map inheritance is to simply assume that the primary key of both tables is the same and that the id field in the class contains the value to be used for both primary keys. The direction of the foreign key constraint should indicate which is the subclass. Yes, 99% of the time this is correct. However, if we want to support compound primary keys there is a need to describe how the columns in the subclass map to the columns in the superclass. That way Cayenne can populate them both correctly. Our original plan was to use an object relationship description in the DataMap to describe this pairing. The alternative is to use the names of the object attributes in order to match the primary key columns to each other, but something about this bothers me as an approach. Also, as Lachlan points out, this means that we don't get to specific nullify, cascade, etc delete rules. If you have a concrete superclass, you may wish to nullify the relationship when deleting the subclass record. Naturally if the superclass is abstract this is not allowed. But specifying the objrelationship explicitly allows us to put these rules somewhere and remove any ambiguity from compound key relationships. Ari --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 PGP.sig Description: This is a digitally signed message part
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi there, On 31/05/2007, at 1:03 PM, Craig L Russell wrote: On May 30, 2007, at 7:23 PM, Lachlan Deck wrote: On 31/05/2007, at 11:54 AM, Lachlan Deck wrote: On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote: On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single-table is well-defined. <...> Okay, so consider the request for superRelationship dropped. (See disclaimer :-) Well that makes it simpler to do all of this ;-) Hang on... Hibernate, for example, does indeed utilise a relationship, to my understanding [1], that specifies the nature of the relationship to the parent, what happens when an object is deleted and so on. These are characteristics that are encapsulated in a relationship. This is why the request for defining a superRelationship in ObjEntity was first made. Perhaps it's an optional for vertical where in its absence is some implicit strategy. Thoughts? The example below shows in Hibernate how to remove the automatically generated relationship between Person and Employee due to the need to map the primary key association to inheritance. I'd even call this a deficiency in the tool, since there is a foreign key constraint defined on the primary key column of the employees table that refers to the primary key column of the persons table. The most natural mapping of this would be inheritance and should therefore be the default. While it might be possible theoretically to define a different column in the database to be used as the association column to join rows of a subclass and a superclass table, by far the most common and most understandable way to map inheritance is to simply assume that the primary key of both tables is the same and that the id field in the class contains the value to be used for both primary keys. The direction of the foreign key constraint should indicate which is the subclass. Sure. (talking from EOF experience again...) the EOF docs for vertical talked about the need for creating a relationship for the case where the tables already exist (and thus their names, for example, may differ) and you're wanting to introduce inheritance (though in practice it needed the relationship either way but that's irrelevant here). However, my question remains this: if not defined in a relationship where does the developer define the delete rules etc? Or are you suggesting they don't get an option? with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On May 30, 2007, at 7:23 PM, Lachlan Deck wrote: On 31/05/2007, at 11:54 AM, Lachlan Deck wrote: On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote: On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single-table is well-defined. <...> Okay, so consider the request for superRelationship dropped. (See disclaimer :-) Well that makes it simpler to do all of this ;-) Hang on... Hibernate, for example, does indeed utilise a relationship, to my understanding [1], that specifies the nature of the relationship to the parent, what happens when an object is deleted and so on. These are characteristics that are encapsulated in a relationship. This is why the request for defining a superRelationship in ObjEntity was first made. Perhaps it's an optional for vertical where in its absence is some implicit strategy. Thoughts? The example below shows in Hibernate how to remove the automatically generated relationship between Person and Employee due to the need to map the primary key association to inheritance. I'd even call this a deficiency in the tool, since there is a foreign key constraint defined on the primary key column of the employees table that refers to the primary key column of the persons table. The most natural mapping of this would be inheritance and should therefore be the default. While it might be possible theoretically to define a different column in the database to be used as the association column to join rows of a subclass and a superclass table, by far the most common and most understandable way to map inheritance is to simply assume that the primary key of both tables is the same and that the id field in the class contains the value to be used for both primary keys. The direction of the foreign key constraint should indicate which is the subclass. Craig with regards, -- Lachlan Deck [1] http://www.warfrog.com/hibernatetutorial2/ Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 11:54 AM, Lachlan Deck wrote: On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote: On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single-table is well-defined. <...> Okay, so consider the request for superRelationship dropped. (See disclaimer :-) Well that makes it simpler to do all of this ;-) Hang on... Hibernate, for example, does indeed utilise a relationship, to my understanding [1], that specifies the nature of the relationship to the parent, what happens when an object is deleted and so on. These are characteristics that are encapsulated in a relationship. This is why the request for defining a superRelationship in ObjEntity was first made. Perhaps it's an optional for vertical where in its absence is some implicit strategy. Thoughts? with regards, -- Lachlan Deck [1] http://www.warfrog.com/hibernatetutorial2/
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 10:44 AM, Mike Kienenberger wrote: On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single-table is well-defined. Fair enough. I'm coming from years in the land of EOF where for vertical inheritance there is indeed a relationship to the parent. But this was needed, I suppose, in order to flatten the parent's attributes/relationships into the child; but there's not much difference, conceptually, for mapping inheritance So really (if that idea was switched for something more JPA friendly) the Inheritance strategy [as I mentioned in the original email 'Modelling improvements: inheritance + interfacing (Draft)'] is still easy determined by these simple conditions: a) is the parent ObjEntity mapped to the same DbEntity? b) is the parent ObjEntity mapped to a DbEntity at all? e.g., a == YES, b == YES --> Inheritance.SINGLE_TABLE a == NO, b == NO--> Inheritance.TABLE_PER_CLASS a == NO, b == YES --> Inheritance.JOINED ... and together with the further condition (isAbstract) also determines whether we're doing a deep fetch, plus whether there's an @DiscriminatorColumn etc. Okay, so consider the request for superRelationship dropped. (See disclaimer :-) Well that makes it simpler to do all of this ;-) I can't remember if the optional horizontal relationships are spelled out in the spec. from: http://java.sys-con.com/read/286901.htm - SINGLE_TABLE: Single-table-per-class inheritance hierarchy. This is the default strategy. The entity hierarchy is essentially flattened into the sum of its fields, and these fields are mapped down to a single table. - JOINED [1]: Common base table, with joined subclass tables. In this approach, each entity in the hierarchy maps to its own dedicated table that maps only the fields declared on that entity. The root entity in the hierarchy is known as the base table, and the tables for all other entities in the hierarchy join with the base table. - TABLE_PER_CLASS [2]: Single-table-per-outermost concrete entity class. This strategy maps each leaf (i.e., outermost, concrete) entity to its own dedicated table. Each such leaf entity branch is flattened, combining its declared fields with the declared fields on all of its super-entities, and the sum of these fields is mapped onto its table. [1] vertical inheritance [2] horizontal inheritance with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 5/30/07, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. When we get to inheritance, we'd be wise to follow the JPA methodology for specifying inheritance relationships. Vertical and single-table is well-defined. I can't remember if the optional horizontal relationships are spelled out in the spec.
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 31/05/2007, at 2:40 AM, Kevin Menard wrote: I'm clearly showing my ignorance on the matter here, but what does it mean for an object to know that it's abstract? Isn't that a property of the class? What happens when you subclass the ObjEntity? Cayenne will need to know this information. For instance, you might have inheritance with an abstract superclass Person. Then performing a query on that class, Cayenne will need to automatically return objects of Student and Tutor subclasses and not the Person superclass. Effectively the flag "setResolvingInherited" will be switched on automatically. If nothing else, this information needs to be stored in the Datamap and the logical place is in the ObjEntity itself. When we get to vertical inheritance there will be at least one other property added to the ObjEntity: the name of the relationship used to find the superclass. Ari Maniatis --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 PGP.sig Description: This is a digitally signed message part
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 30/05/2007, at 3:04 PM, Lachlan Deck wrote: On 29/05/2007, at 11:02 PM, Andrus Adamchik wrote: Ok, I overlooked the issue of DB mapping of abstract entities that do not have a DbEntity. IIRC this issue was raised when we discussed embeddables. Not sure we came to any conclusion back then. So is this what proposed "DbEntity interfaces" are for? I'm not familiar with the embeddable discussion but this is the idea of DbEntity interfaces: a) you have a series of DbEntities that are not inherited in any way but for which you want them to conform to an interface 'A'. They are explicitly tied to that interface (rather than having to synchronise to it). i.e., the attributes/relations appear as they do for inherited characteristics. i.e., they're defined once per model and implemented by various other DbEntities. b) an ObjEntity interface 'a' may optionally map to a DbEntity interface 'b'. Any ObjEntity 'c' that maps to a DbEntity that implements 'b' will be shown to implicitly implement the associated ObjEntity 'a'. c) then there are the ObjEntity interfaces that have no associated DbEntity interface... Maybe we can simplify that and continue mapping abstract attributes (be for abstract ObjEntities or Embeddables) by simply specifying a "db attribute name", allowing to override it in a concrete definition? This is very close to how JPA suggests to do it, would cut down on the separate interface definitions, and allow to reuse the existing XML format without change (except for "isAbstract" flag). On further reflection, isn't that concept similar to the EOF's EO [Adaptor]Prototypes? i.e., defining abstract attributes (e.g., nameField_varchar(64)) that can be utilised by various non-abstract attributes in any DbEntity. The concept I'm suggesting, however, allows a protocol to be defined that a DbEntity adheres to rather than an individual attribute. Such protocols, of course, can, via inheritance, be the combination of a few interfaces. Sounds like a supporting concept. i.e., an interface provides for a specification that includes attributes x, y, & z with certain constraints. An abstract attribute on its own would be useful within an interface. with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 5/30/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: info by any kind of task. But you'd never have a WORK_ORDER entry without a subclass table. Thus, the template generator should never create WorkOrder as an abstract class. Ugh. This should have been "would always create WorkOrder as an abstract class".
RE: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Gotcha. That makes a lot more sense now. Thanks, Kevin > -Original Message- > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 12:47 PM > To: [email protected] > Subject: Re: Abstract Entities [Was: Modelling improvements: > inheritance + interfacing (Draft)] > > Hi Kevin, > > Let me guess the answer to this one. > > First we're talking about an ObjEntity, not a DataObject. So you'd > never subclass it. > > As an example, one of my projects has WORK_ORDER, > DISCONNECT_ORDER, CONNECT_ORDER (and so on) tables. > WORK_ORDER is the common shared > info by any kind of task. But you'd never have a WORK_ORDER entry > without a subclass table. Thus, the template generator should never > create WorkOrder as an abstract class.DisconnectOrder and > ConnectOrder would inherit from that class and would not be abstract.
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Hi Kevin, Let me guess the answer to this one. First we're talking about an ObjEntity, not a DataObject. So you'd never subclass it. As an example, one of my projects has WORK_ORDER, DISCONNECT_ORDER, CONNECT_ORDER (and so on) tables. WORK_ORDER is the common shared info by any kind of task. But you'd never have a WORK_ORDER entry without a subclass table. Thus, the template generator should never create WorkOrder as an abstract class.DisconnectOrder and ConnectOrder would inherit from that class and would not be abstract. On 5/30/07, Kevin Menard <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Aristedes Maniatis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 4:32 AM > To: [email protected] > Subject: Re: Abstract Entities [Was: Modelling improvements: > inheritance + interfacing (Draft)] > > > * Changes to the code generation templates to generate > abstract java > > classes for such entities > > Yes and the setIsAbstract() and getIsAbstract() functions for > ObjEntity which go hand in hand. I'm clearly showing my ignorance on the matter here, but what does it mean for an object to know that it's abstract? Isn't that a property of the class? What happens when you subclass the ObjEntity? -- Kevin
RE: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
> -Original Message- > From: Aristedes Maniatis [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 30, 2007 4:32 AM > To: [email protected] > Subject: Re: Abstract Entities [Was: Modelling improvements: > inheritance + interfacing (Draft)] > > > * Changes to the code generation templates to generate > abstract java > > classes for such entities > > Yes and the setIsAbstract() and getIsAbstract() functions for > ObjEntity which go hand in hand. I'm clearly showing my ignorance on the matter here, but what does it mean for an object to know that it's abstract? Isn't that a property of the class? What happens when you subclass the ObjEntity? -- Kevin
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On May 30, 2007, at 7:27 AM, Lachlan Deck wrote: * Changes to the validation rules to allow ObjEntity with no db entity for abstract entities The question of 'isAbstract' is merely a question of 'can instances of this entity be instantiated'? Certainly changes to validation rules are necessary. But it is possible for an entity to be both abstract whilst having an associated db entity (e.g., vertical inheritance where the developer doesn't desire to instantiate instances of parent entity). Right. I guess ObjEntity without a DbEntity feature can be tucked onto one of the inheritance tasks. * maybe also some runtime checks for abstract entity (???) The only runtime checks I can foresee at the moment are: - a CayenneRuntimeException for attempting to do a fetch on an ObjEntity that has no associated db entity. Other logic will need to be in place that determines how deep the fetch is. e.g., if there's a SelectQuery on a parent entity that's abstract then this would imply a deep fetch (i.e., of sub-entity instances). If however the parent is not abstract then (even for horizontal inheritance) instances of the parent are fetched (resolving attributes appropriately from children for horizontal). This may also be a part of the inheritance discussion, but here is a one thing to note: SelectQuery (and other queries) supports "setResolvingInherited", which is a deep-fetch vs. no-deep-fetch flag. Andrus
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 29/05/2007, at 8:01 PM, Andrus Adamchik wrote: Trying to decompose it further (so that we could Jira individual chunks easily :-))... +1 for the abstract entities support, but they can also be implemented as a separate feature independent from inheritance per se. needs the following additional (optional) xml attributes: - isAbstract="flag" +1 Also the following steps will be needed: * Modeler checkbox for ObjEntity "abstract" flag Yes. * Changes to the code generation templates to generate abstract java classes for such entities Yes and the setIsAbstract() and getIsAbstract() functions for ObjEntity which go hand in hand. * Changes to the validation rules to allow ObjEntity with no db entity for abstract entities Actually I don't think that is needed for this first step. That is needed for step 2: horizontal inheritance. * maybe also some runtime checks for abstract entity (???) I think the main one is that you cannot perform a SelectQuery (or anything else that returns an ObjEntity) on an abstract entity with no concrete subclasses. Kind of makes isAbstract a bit useless on its own, but it is a step in the right direction. Ari --> Aristedes Maniatis phone +61 2 9660 9700 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 PGP.sig Description: This is a digitally signed message part
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 29/05/2007, at 11:02 PM, Andrus Adamchik wrote: Ok, I overlooked the issue of DB mapping of abstract entities that do not have a DbEntity. IIRC this issue was raised when we discussed embeddables. Not sure we came to any conclusion back then. So is this what proposed "DbEntity interfaces" are for? I'm not familiar with the embeddable discussion but this is the idea of DbEntity interfaces: a) you have a series of DbEntities that are not inherited in any way but for which you want them to conform to an interface 'A'. They are explicitly tied to that interface (rather than having to synchronise to it). i.e., the attributes/relations appear as they do for inherited characteristics. i.e., they're defined once per model and implemented by various other DbEntities. b) an ObjEntity interface 'a' may optionally map to a DbEntity interface 'b'. Any ObjEntity 'c' that maps to a DbEntity that implements 'b' will be shown to implicitly implement the associated ObjEntity 'a'. c) then there are the ObjEntity interfaces that have no associated DbEntity interface... Maybe we can simplify that and continue mapping abstract attributes (be for abstract ObjEntities or Embeddables) by simply specifying a "db attribute name", allowing to override it in a concrete definition? This is very close to how JPA suggests to do it, would cut down on the separate interface definitions, and allow to reuse the existing XML format without change (except for "isAbstract" flag). What do you think? Sounds like a supporting concept. i.e., an interface provides for a specification that includes attributes x, y, & z with certain constraints. An abstract attribute on its own would be useful within an interface. with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
On 29/05/2007, at 8:01 PM, Andrus Adamchik wrote: Trying to decompose it further (so that we could Jira individual chunks easily :-))... +1 for the abstract entities support, but they can also be implemented as a separate feature independent from inheritance per se. True. needs the following additional (optional) xml attributes: - isAbstract="flag" +1 Also the following steps will be needed: * Modeler checkbox for ObjEntity "abstract" flag * Changes to the code generation templates to generate abstract java classes for such entities Yep. * Changes to the validation rules to allow ObjEntity with no db entity for abstract entities The question of 'isAbstract' is merely a question of 'can instances of this entity be instantiated'? Certainly changes to validation rules are necessary. But it is possible for an entity to be both abstract whilst having an associated db entity (e.g., vertical inheritance where the developer doesn't desire to instantiate instances of parent entity). * maybe also some runtime checks for abstract entity (???) The only runtime checks I can foresee at the moment are: - a CayenneRuntimeException for attempting to do a fetch on an ObjEntity that has no associated db entity. Other logic will need to be in place that determines how deep the fetch is. e.g., if there's a SelectQuery on a parent entity that's abstract then this would imply a deep fetch (i.e., of sub-entity instances). If however the parent is not abstract then (even for horizontal inheritance) instances of the parent are fetched (resolving attributes appropriately from children for horizontal). with regards, -- Lachlan Deck
Re: Abstract Entities [Was: Modelling improvements: inheritance + interfacing (Draft)]
Ok, I overlooked the issue of DB mapping of abstract entities that do not have a DbEntity. IIRC this issue was raised when we discussed embeddables. Not sure we came to any conclusion back then. So is this what proposed "DbEntity interfaces" are for? Maybe we can simplify that and continue mapping abstract attributes (be for abstract ObjEntities or Embeddables) by simply specifying a "db attribute name", allowing to override it in a concrete definition? This is very close to how JPA suggests to do it, would cut down on the separate interface definitions, and allow to reuse the existing XML format without change (except for "isAbstract" flag). What do you think? Andrus On May 29, 2007, at 1:01 PM, Andrus Adamchik wrote: Trying to decompose it further (so that we could Jira individual chunks easily :-))... +1 for the abstract entities support, but they can also be implemented as a separate feature independent from inheritance per se. needs the following additional (optional) xml attributes: - isAbstract="flag" +1 Also the following steps will be needed: * Modeler checkbox for ObjEntity "abstract" flag * Changes to the code generation templates to generate abstract java classes for such entities * Changes to the validation rules to allow ObjEntity with no db entity for abstract entities * maybe also some runtime checks for abstract entity (???) Thanks Andrus
