Hey Angelo,
As far as your statement:
1) I prefer to implement my business logic in my custom classes rather than in SQL code that will often be hard to maintain and that will almost certainly be tailored for a specific RDBMS. Anyway, what is the point in having custom classes and the power of Enterprise Objects if I must rely on custom-tailored SQL code?
Amen, brother! You are 100% right. If you are not forced into working with a legacy database, you should **not** be doing a bunch of work-around, hacky BS with derived attributes/relationships or read/write formatters. Store the data in the DB how you want to use it. Why have an ORM if you are still forced to write SQL? And even if you are forced to use an existing column, there are ways to do what you want using Java instead. See the “boolean” erprototype. It is an example of using a “Custom" Data Type in Entity Modeler which you can use specify your own Java class to do the read/write transformations instead of writing db-specific SQL.
As far as the rest of the issues you describe, there is something very wrong. The things you describe in point 2 and 3 below should not be happening.
How have you modeled these three entities? (Party, Person, Organization)
What type of Inheritance are you using? (SingleTable, Vertical, Horizontal)
How are the entities represented in the database? (one table, two tables, three tables)
With EOF the EOModel is EVERYTHING. If you don’t get it right, you will be writing a huge amount of code to try to make EOF do what you really want and it will likely still not do it every time.
If you get the EOModel right, then the code will seem to write itself and all this work you are doing will just go away.
I’m going to be in-and-out all day today, but if you can zip and attach your .eomodeld file, I’ll look it over to see if I (or anybody else) can spot where things have gone wrong for you.
Dave
On Mar 24, 2014, at 5:16 PM, Ângelo Andrade Cirino < email@hidden> wrote: Hi Dave,
It is a minor bug, but still a bug. When I have time I will give it a look.
I am working with the derived attributes with no major complaints now. Still, there are some problems with EO and derived attributes.
1) I prefer to implement my business logic in my custom classes rather than in SQL code that will often be hard to maintain and that will almost certainly be tailored for a specific RDBMS. Anyway, what is the point in having custom classes and the power of Enterprise Objects if I must rely on custom-tailored SQL code?
So, I simply create a derived attribute and then I override it in my custom class, and then forget the existence of the derived attribute. To make my typing shorter I tried to include dummies for the SQL statement, as simple as returning an empty string, ''. But EO did not interpret correctly my reasoning and tried to use it with an error. I ended using a very stupid dummy for all my derived attributes, since I want the model to be database agnostic. I use if(TRUE,NULL,NULL) and then override the derived attributes with my custom logic in my custom classes. I am currently not concerned with database performance, I am just trying to develop a valid programming technique for the context of D2W applications.
2) I implemented two derived classes, Person and Organization, since both are a Party. The subclasses are differentiated by the type attribute. Up to a point EO will deal with the Party entity very well, essentially when I try to access only the attributes or derived attributes that are common to both subclasses. When I needed the equivalent of this SQL statement
select distinct party.id, party.created, party.lastmodified, if(party.status = 0,'Active','Inactive') as status, if(party.type = 0, 'Natural Person', 'Legal person') as type,
( case party.type when 0 then concat(person.firstName, ' ', person.lastName)
end ) as fullName from party inner join person, organization where (party.personID = person.id or party.organizationID = organization.id);
EO returned an empty set, because it used party.personID = person.id AND party.organizationID = organization.id instead of OR as my SQL statement. Whenever I constructed a derived attribute with columns from both tables EO generates the SQL inner join clause with an AND instead of an OR. I found no way to solve this problem and that's one of the reasons I moved to dummy derived attributes statements.
3) In simple listings for the base class, Party, EO will generate a very similar SQL statement but will effectively lack the DISTINCT clause doubling the result set. This happens for queries too. For the listings I circumvented the problem by creating a allParties fetch specification in my Party entity
type = 0 OR type = 1
and then implementing the list page this way
public WOComponent listPartyAction() { ListPageInterface newListPage = (ListPageInterface)D2W.factory().pageForConfigurationNamed("List" + Party.ENTITY_NAME, session()); EODataSource ds = new ERXDatabaseDataSource(ERXEC.newEditingContext(), Party.ENTITY_NAME, "allParties"); newListPage.setDataSource(ds); return (WOComponent) newListPage; }
This way my list page displays the correct set of EO objects. I still have to work on the query issue with an adequate delegate implementing an additional fetch specification, but I deferred the solution to a later moment since it is already identified and easily implemented.
I am not sure if I am being naive or using EO in a very stupid way (or both perhaps, since stupidity comes after naivety). I would appreciate any sincere and frank comments and criticisms, since I am doing all this in a huge effort to deepen my understanding of EO and Wonder and then become a better WO developer, hoping to contribute to the community instead of only asking silly questions.
Regards,
Angelo
—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™ ————————————————————————————— David Avendasora Senior Software Abuser Nekesto, Inc.
|