Hi Xavier,
Hmmm. As a complete aside to the SQL generation issue, are you _sure_ you need
inheritance for this?
In your app, what happens if an employee wants to buy something from you? They
can't be both a customer and an employee. Don't make the mistake of thinking
you can change change which class a person is.
Using inheritance in this type of situation is almost always the wrong way to
go. I'd probably model this as a person being able to have multiple roles and
you'd get all the customers by doing something along the lines of "Get all
person objects that have relationship to the customer type." In Wonder:
NSArray<Person> customers = Person.fetchAll(ec,
Person.ROLES.contains(Role.customerRole()));
You can then have different behaviors for different roles by using delegates
that encapsulate the role-specific behaviors. Replace the idea of IS-A (person)
with HAS-A (role).
Much more flexible, and it gets rid of Inheritance in your EOModel.
Dave
On Feb 2, 2011, at 3:42 PM, Dev WO wrote:
> Sure Dave, here they are:
>
> parent entity
> {
> attributes = (
> {allowsNull = N; name = id; prototypeName = id; },
> {allowsNull = Y; columnName = name; name = name; prototypeName =
> varchar255; }
> );
> attributesUsedForLocking = (id);
> className = "com.anazys.tempFrameworkWonder54.Core";
> classProperties = (name);
> fetchSpecificationDictionary = {};
> isAbstractEntity = Y;
> name = Core;
> primaryKeyAttributes = (id);
> }
>
> subclass Employee
> {
> attributes = (
> {allowsNull = N; name = id; prototypeName = id; },
> {allowsNull = Y; columnName = name; name = name; prototypeName =
> varchar255; }
> );
> attributesUsedForLocking = (id);
> className = "com.anazys.tempFrameworkWonder54.Employee";
> classProperties = (name);
> externalName = Employee;
> fetchSpecificationDictionary = {};
> name = Employee;
> parent = Core;
> primaryKeyAttributes = (id);
> }
>
> subclass Customer
> {
> attributes = (
> {allowsNull = N; name = id; prototypeName = id; },
> {allowsNull = Y; columnName = name; name = name; prototypeName =
> varchar255; }
> );
> attributesUsedForLocking = (id);
> className = "com.anazys.tempFrameworkWonder54.Customer";
> classProperties = (name);
> externalName = Customer;
> fetchSpecificationDictionary = {};
> name = Customer;
> parent = Core;
> primaryKeyAttributes = (id);
> }
>
> I could edit the code for the SQL when generating the database, but the issue
> is really in production, if I update the app, it will start to generate pk
> based on the sub-entity, and I will end up with duplicate pks between various
> sub-classes.
> So the SQL generated by EntityModeler is just a way to check if it's going to
> break the current app, not really for that specific action.
>
> Xavier
>
>
> On 2 févr. 2011, at 19:05, David Avendasora wrote:
>
>> Hi Xavier,
>>
>> Can you paste the .plist files for the three Entities (the super and two
>> subclasses) into this email? I'm suspecting that there maybe something wrong
>> with the way it is modeled...
>>
>> What if you manually create the database tables and the sequence instead of
>> letting EntityModeler generate the SQL for them? Does creating and saving
>> new instances of the subclasses work? What I'm trying to figure out is if
>> this is a problem with just the Create Table statements generated by the
>> plugin, or a more fundamental problem with how EOF is using Horizontal
>> Inheritance.
>>
>> Dave
>>
>> On Feb 2, 2011, at 12:46 PM, Dev WO wrote:
>>
>>> Hello Chuck,
>>>
>>> With JavaERJDBCAdaptor or the default JavaJDBCAdaptor, the result is the
>>> same, it doesn't conform to the inheritance modeled in EntityModeler.
>>> I've got to check into ERExtensions if I can find something.
>>>
>>> I understand not everyone is using Horizontal Inheritance, but I must not
>>> be the only one trying to figure out what's going on with 5.4.
>>>
>>> Just to make sure, I've created a new Wonder framework, created only an
>>> abstract entity and 2 sub-entities with horizontal inheritance, and the
>>> generated SQL is not correct, it doesn't conform to the modeled inheritance
>>> by requesting sequence for the pk for each sub-entity instead of the
>>> abstract parent sequence.
>>> It looks to me this is a bug, I'm not 100% sure it's in Wonder or
>>> Webobjects though. Should I fill a Jira for this? I don't think this could
>>> be qualified as a regression as I don't even know if this bug was ever in
>>> 5.3.
>>>
>>> Thanks for your help,
>>>
>>> Xavier
>>>
>>> On 1 févr. 2011, at 20:24, Chuck Hill wrote:
>>>
>>>> Hi Xavier,
>>>>
>>>>
>>>> On Feb 1, 2011, at 12:42 AM, Dev WO wrote:
>>>>
>>>>> I'm still trying to figure out what's happening...
>>>>> What I have found so far is that:
>>>>>
>>>>> If I'm doing:
>>>>> -latest 5.4 wonder frameworks except JavaERJDBCAdaptor.framework and
>>>>> PostgresqlPlugIn.framework from 5.3
>>>>> -binding to WebObjects 5.4 (using
>>>>> wo.system.frameworks=/System/Library/Frameworks/WebObjects54 in my
>>>>> wolips.properties)
>>>>> => SQL generation doesn't conform to entity inheritance
>>>>>
>>>>> If I'm doing:
>>>>> -latest 5.4 wonder frameworks
>>>>> -binding to WebObjects 5.4 (using
>>>>> wo.system.frameworks=/System/Library/Frameworks/WebObjects54 in my
>>>>> wolips.properties)
>>>>> => SQL generation doesn't conform to entity inheritance
>>>>
>>>> Try it without JavaERJDBCAdaptor.framework at all (just use
>>>> JavaJDBCAdaptor.framework)
>>>>
>>>>
>>>>> if I'm doing:
>>>>> -lastest 5.3 wonder frameworks
>>>>> -binding to WebObjects 5.3 (using
>>>>> wo.system.frameworks=/System/Library/Frameworks/WebObjects53 in my
>>>>> wolips.properties)
>>>>> => I've got the correct behavior which is inheritance enforced when
>>>>> generating the SQL in EntityModeler.
>>>>>
>>>>> So I can say there is something different regarding horizontal
>>>>> inheritance between WebObjects 5.3 and WebObjects 5.4. Based on the first
>>>>> case scenario, it seems the difference occurs within WebObjects
>>>>> frameworks (but maybe something else is involved in the Wonder frameworks
>>>>> in addition to the 2 I keept from 5.3 in the first case).
>>>>>
>>>>> I don't know if this is to be considered a bug or if there's just
>>>>> something I should add/edit to make horizontal inheritance works under a
>>>>> complete 5.4 setup, but the fact that I couldn't find the same issue on
>>>>> the list makes me feel like the issue could at least be fixed on my side.
>>>>
>>>> It might be that few people are using Horizontal Inheritance. I have
>>>> not noticed any problem with Single Table Inheritance.
>>>>
>>>>
>>>>> Any pointer about where to look at to ensure proper horizontal
>>>>> inheritance SQL generation under 5.4?
>>>>
>>>> Based on your evidence, I'd search for "primary" in ERExtensions. If
>>>> nothing else, that will at least show you were in EOF the PK generation
>>>> happens.
>>>>
>>>>
>>>> Chuck
>>>>
>>>>
>>>>> On 31 janv. 2011, at 18:57, Dev WO wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I don't really know where the issue come from, but here's what's
>>>>>> happening and what I've already tried to fix it (without a solution so
>>>>>> far).
>>>>>>
>>>>>> I'm using Eclipse 3.6.1.M20100909 cocoa 64
>>>>>> WOLips 3.6.6215
>>>>>> PostgreSQL 8.4
>>>>>> WO 5.4.3
>>>>>>
>>>>>> My previous setup was WO 5.3.3 with the previous major version of
>>>>>> Eclipse (Carbon) and WOLips. The following behavior wasn't happening in
>>>>>> this setup.
>>>>>>
>>>>>> I've got an Abstract entity A and a couple sub-entities, let's say SubA1
>>>>>> and SubA2.
>>>>>> In the previous setup, when I generated the SQL for them, they were both
>>>>>> correctly referring to A_seq for their primary key generation (in
>>>>>> EntityModeler when generating SQL and while the app was running).
>>>>>> Now they are referring to SubA1_seq and SubA2_seq (in EntityModeler and
>>>>>> while the app is running) which breaks the entire application by
>>>>>> providing pk that might be already taken by the other sub-entity...
>>>>>>
>>>>>> I first thought it could come from the PosgreSQL plugin framework, but
>>>>>> after putting back my previous one, the issue is still there (cleaned
>>>>>> the project after "updating" the framework).
>>>>>>
>>>>>> I'll will update WOLips right away to check if it changes anything, but
>>>>>> if anyone has an idea on what might cause this issue and even better how
>>>>>> to fix it to respect entity inheritance, that would be really nice:)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Xavier
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list ([email protected])
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40anazys.com
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Webobjects-dev mailing list ([email protected])
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>>
>>>>> This email sent to [email protected]
>>>>
>>>> --
>>>> Chuck Hill Senior Consultant / VP Development
>>>>
>>>> Practical WebObjects - for developers who want to increase their overall
>>>> knowledge of WebObjects or who are trying to solve specific problems.
>>>> http://www.global-village.net/products/practical_webobjects
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list ([email protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>
>>> This email sent to [email protected]
>>>
>>>
>>
>>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
