Re: using primary and foreign keys as class properties
Steven,
I have just begun to really get into the Project Wonder framework,
and it looks like ERXGenericRecord provides nice ways to get at the
keys easily without writing 3-6 lines of code each time (why didn't
I think of the methods that ERXGenericRecord provides earlier?).
Thanks to Kieran for that suggestion.
Why would you need to write 3-6 lines of code "each time" when you
can just create a little helper class to get the PK/FK from any EO like:
..
public String unaryPKValueForObject(EOEnterpriseObject eo) {
NSDictionary d = EOUtilities.primaryKeyForObject
(eo.editingContext(), eo);
Number n = (Number)d.objectForKey("oid");
return n.toString();
}
..
String pk = myEOHelper.sharedInstance().unaryPKValueForObject(myEO);
The above is just a truncated example, but I use something like this
to interface to direct actions that lookup objects by PK.
The point is that there are other design patterns to keep things DRY
(Don't Repeat Yourself) by not repeating the same code on every EO
that you create.
But of course the abstraction provided by ERXGenericRecord is
certainly another (possibly better) way to go.
On Feb 4, 2007, at 12:24 PM, Steven Mark McCraw wrote:
Hi Pierre,
First off, thanks for the response (and thanks to the others who
responded earlier). It is good to hear from someone at Apple who
is familiar with the code. It sounds like the smart thing to do is
not to add keys as class properties directly, since EOF might have
some branch in the future that follows through on the assumption
that they aren't.
I have just begun to really get into the Project Wonder framework,
and it looks like ERXGenericRecord provides nice ways to get at the
keys easily without writing 3-6 lines of code each time (why didn't
I think of the methods that ERXGenericRecord provides earlier?).
Thanks to Kieran for that suggestion.
As to the question of whether writing custom SQL code is poor
design, I certainly don't want to get into an argument about it.
I'm sure sticking totally with EOF for database communication has
advantages, and I spent many, many hours (probably amounting to
weeks or months) trying to keep within those parameters based upon
the documentation that I have read that advocates doing so.
My real world experience taught me the hard way that sometimes (if
you need to do quick optimized fetches on data sets with more than
a few thousand records that span several tables) you can save lots
and lots of time (not to mention lots and lots of memory) just
generating custom SQL to get raw rows. It's far easier to
optimize, and you don't have to deal with the time and memory
overhead of encapsulating the data as a set of full fledged
enterprise objects (In a large hitlist the user will probably not
drill down for detail on the vast majority of these rows anyway).
The strategy of fetching the display hitlist as raw rows and then
creating an EO for use only when a user selects the row for a more
detailed view has worked out really well for me, and I've found
that managing the SQL isn't really more complicated than managing a
complex fetch specification. It's felt very liberating, actually,
to code this way, and when combined with using a connection pool
for non-EOF database communication, it's very, very fast compared
to EOF (even when using all the tricks like prefetching, batch
faulting, etc).
I've been using this paradigm for several years now and have yet to
experience any downside. I've had far less grief with it than the
days and days I used to spend trying to optimize EOF to acceptable
performance levels (acceptable from the customer's point of view).
I'm not trying to pretend that this method is the height of clean
design (I'm no more thrilled with embedding complex custom SQL in
my application layer than I am with embedding complex
EOFetchSpecification construction), but it is pragmatic, and I
would encourage developers to at least think through the possible
benefits and harms before simply writing it off as an option (as I
did for years). It's easy to say that it's a bad approach until
you've actually tried it and seen it work.
I would welcome any more thoughts or discussion on the subject, and
again, appreciate the feedback thus far.
Sincerely,
Mark
On Feb 4, 2007, at 11:30 AM, Mr. Pierre Frisch wrote:
Hi Mark,
Before setting primary keys as class properties I would really
question my design. This question typically occurs when you use
the primary to convey meaning about the object and this can
usually better be expressed in the object itself. This will give
you a better object design and a more readable code. In 10 years
developing with WebObjects I am yet to see a problem that could
not be worked around that way. Primary key should left at the
database layer. The application layer shoul
Re: using primary and foreign keys as class properties
Steven Mark McCraw wrote on 2/3/07 6:36 PM: I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). I'm chiming in rather late here, but there is at least one specific circumstance when exposing FKs will cause tremendous pain: When an EO has (1) a required relation, (2) the relation's FK is marked as required and (3) the FK is available as a class property, EOF will choke when you try to persist new objects because validation happens before PK generation. That is, if the relationship-owner and the relationship-destination are both new objects, validation of the relationship-owner's FK will fail because the destination object hasn't had its PK generated yet. An earlier discussion about this problem is here: http://www.omnigroup.com/mailman/archive/webobjects-dev/2006-December/002760.html That discussion focuses on model validation with Eclipse/Entity Modeler, bu the issue is the same. FWIW, I have PKs exposed all over the place in my apps, mainly as hooks for DirectAction pages, and that's never caused me any kind of problem. Cheers, zak. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: using primary and foreign keys as class properties
Hi Pierre, First off, thanks for the response (and thanks to the others who responded earlier). It is good to hear from someone at Apple who is familiar with the code. It sounds like the smart thing to do is not to add keys as class properties directly, since EOF might have some branch in the future that follows through on the assumption that they aren't. I have just begun to really get into the Project Wonder framework, and it looks like ERXGenericRecord provides nice ways to get at the keys easily without writing 3-6 lines of code each time (why didn't I think of the methods that ERXGenericRecord provides earlier?). Thanks to Kieran for that suggestion. As to the question of whether writing custom SQL code is poor design, I certainly don't want to get into an argument about it. I'm sure sticking totally with EOF for database communication has advantages, and I spent many, many hours (probably amounting to weeks or months) trying to keep within those parameters based upon the documentation that I have read that advocates doing so. My real world experience taught me the hard way that sometimes (if you need to do quick optimized fetches on data sets with more than a few thousand records that span several tables) you can save lots and lots of time (not to mention lots and lots of memory) just generating custom SQL to get raw rows. It's far easier to optimize, and you don't have to deal with the time and memory overhead of encapsulating the data as a set of full fledged enterprise objects (In a large hitlist the user will probably not drill down for detail on the vast majority of these rows anyway). The strategy of fetching the display hitlist as raw rows and then creating an EO for use only when a user selects the row for a more detailed view has worked out really well for me, and I've found that managing the SQL isn't really more complicated than managing a complex fetch specification. It's felt very liberating, actually, to code this way, and when combined with using a connection pool for non-EOF database communication, it's very, very fast compared to EOF (even when using all the tricks like prefetching, batch faulting, etc). I've been using this paradigm for several years now and have yet to experience any downside. I've had far less grief with it than the days and days I used to spend trying to optimize EOF to acceptable performance levels (acceptable from the customer's point of view). I'm not trying to pretend that this method is the height of clean design (I'm no more thrilled with embedding complex custom SQL in my application layer than I am with embedding complex EOFetchSpecification construction), but it is pragmatic, and I would encourage developers to at least think through the possible benefits and harms before simply writing it off as an option (as I did for years). It's easy to say that it's a bad approach until you've actually tried it and seen it work. I would welcome any more thoughts or discussion on the subject, and again, appreciate the feedback thus far. Sincerely, Mark On Feb 4, 2007, at 11:30 AM, Mr. Pierre Frisch wrote: Hi Mark, Before setting primary keys as class properties I would really question my design. This question typically occurs when you use the primary to convey meaning about the object and this can usually better be expressed in the object itself. This will give you a better object design and a more readable code. In 10 years developing with WebObjects I am yet to see a problem that could not be worked around that way. Primary key should left at the database layer. The application layer should manipulate EOGlobalID you will save you self and the developer that will fix your code after you a lot of trouble and time by keeping that encapsulation. You are right EOF make the assumption that primary keys are not class property. I do not think anything break in the current version if you make them class properties and consider them as read only but that is not guaranteed for the future. Primary Keys are considered private to the EOControl layer and should only be accessed directly if you are writing extension to that layer. As for optimizing there are lots of way of doing it within EOF and for the same reason you should probably try those very hard before writing custom SQL code. The same apply here I have used all sort of delegate and even written custom qualifiers but I have always stuck to the rule that I do not embed SQL code in the application layer. If you are missing feature to optimize your application please file a bug report. I promise that it will be read. Thanks Pierre -- Pierre Frisch [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update
Re: using primary and foreign keys as class properties
Hi Mark, Before setting primary keys as class properties I would really question my design. This question typically occurs when you use the primary to convey meaning about the object and this can usually better be expressed in the object itself. This will give you a better object design and a more readable code. In 10 years developing with WebObjects I am yet to see a problem that could not be worked around that way. Primary key should left at the database layer. The application layer should manipulate EOGlobalID you will save you self and the developer that will fix your code after you a lot of trouble and time by keeping that encapsulation. You are right EOF make the assumption that primary keys are not class property. I do not think anything break in the current version if you make them class properties and consider them as read only but that is not guaranteed for the future. Primary Keys are considered private to the EOControl layer and should only be accessed directly if you are writing extension to that layer. As for optimizing there are lots of way of doing it within EOF and for the same reason you should probably try those very hard before writing custom SQL code. The same apply here I have used all sort of delegate and even written custom qualifiers but I have always stuck to the rule that I do not embed SQL code in the application layer. If you are missing feature to optimize your application please file a bug report. I promise that it will be read. Thanks Pierre -- Pierre Frisch [EMAIL PROTECTED] On 3-Feb-07, at 3:36 PM, Steven Mark McCraw wrote: Hi everyone, I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). Over the years, I've often thought it would be convenient to have the keys as class properties, particularly when I've had to write custom queries. I know EOUtilities gives you methods to get the primary and foreign keys for an object, but using these are kind of a pain compared to just calling a simple accessor method. I've actually set keys as class properties a few times, but whenever a strange EOF exception cropped up, this was the first thing I always changed back (in a rather superstitious, paranoid way) for fear that somehow having the keys as class properties was giving EOF a fit. I started thinking about it again the other day for some reason, and frankly I can't think of any reason it should have an effect on EOF, so I thought I would pose the question to the list. Is having keys as class properties just something that is for some reason considered "bad form" by the early documentation writers at Apple (I recall the same documentation firmly asserting that you never need to do anything outside EOF, but in the real world this isn't always practical when you need to optimize)? Or is there in fact something about having keys as class properties that throws a monkey wrench into EOF at unpredictable times? Thanks in advance for help/discussion. Mark ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/pierre% 40apple.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: using primary and foreign keys as class properties
Hi! You could set primary keys as class properties - provided you don't go modify their values. I'd say the best approach - if you really, really need those values - is to set them as read-only class properties. Make sure your eogenerator template checks for read-only attributes and omits the respective setter methods. Best, Pierre Bernard Houdah Software s.à r.l. On 4 Feb 2007, at 00:36, Steven Mark McCraw wrote: Hi everyone, I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). Over the years, I've often thought it would be convenient to have the keys as class properties, particularly when I've had to write custom queries. I know EOUtilities gives you methods to get the primary and foreign keys for an object, but using these are kind of a pain compared to just calling a simple accessor method. I've actually set keys as class properties a few times, but whenever a strange EOF exception cropped up, this was the first thing I always changed back (in a rather superstitious, paranoid way) for fear that somehow having the keys as class properties was giving EOF a fit. I started thinking about it again the other day for some reason, and frankly I can't think of any reason it should have an effect on EOF, so I thought I would pose the question to the list. Is having keys as class properties just something that is for some reason considered "bad form" by the early documentation writers at Apple (I recall the same documentation firmly asserting that you never need to do anything outside EOF, but in the real world this isn't always practical when you need to optimize)? Or is there in fact something about having keys as class properties that throws a monkey wrench into EOF at unpredictable times? Thanks in advance for help/discussion. Mark ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/webobjects- lists%40houdah.com This email sent to [EMAIL PROTECTED] - - - Houdah Software s. à r. l. http://www.houdah.com - Quality Mac OS X software - Premium WebObjects consulting ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: using primary and foreign keys as class properties
Alternatively, you could just create your own subclass of EOGenericRecord and for all your EO's and put cover methods for the EOUtilities methods in there. Implementing that is easy if you are using eogenerator just change the extends in the generation gap template and regenerate. Look at Project Wonder ERXGenericRecord subclass if you have PW, you can still subclass *that* class to get those key values, for example ERXGenericRecord.primaryKey(), ERXGenericRecord.rawPrimaryKey() (Since Art says Aloha, I have to say it in Irish :-p ) Slán, Kieran On Feb 3, 2007, at 6:36 PM, Steven Mark McCraw wrote: Hi everyone, I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). Over the years, I've often thought it would be convenient to have the keys as class properties, particularly when I've had to write custom queries. I know EOUtilities gives you methods to get the primary and foreign keys for an object, but using these are kind of a pain compared to just calling a simple accessor method. I've actually set keys as class properties a few times, but whenever a strange EOF exception cropped up, this was the first thing I always changed back (in a rather superstitious, paranoid way) for fear that somehow having the keys as class properties was giving EOF a fit. I started thinking about it again the other day for some reason, and frankly I can't think of any reason it should have an effect on EOF, so I thought I would pose the question to the list. Is having keys as class properties just something that is for some reason considered "bad form" by the early documentation writers at Apple (I recall the same documentation firmly asserting that you never need to do anything outside EOF, but in the real world this isn't always practical when you need to optimize)? Or is there in fact something about having keys as class properties that throws a monkey wrench into EOF at unpredictable times? Thanks in advance for help/discussion. Mark ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists% 40mac.com This email sent to [EMAIL PROTECTED] ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
Re: using primary and foreign keys as class properties
On Feb 3, 2007, at 1:36 PM, Steven Mark McCraw wrote: I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). A problem with doing this would be that setting a primary key will raise an exception because EOF doesn't allow primary keys to be updated. Setting a foreign key directly will likely confuse EOF because the object graph will then be inconsistent. So setters for primary and foreign keys should not be used but will be available to be used unless you manually remove them from the class implementation and remember to do so whenever you regenerate class implementations using EOModeler or eogenerator. Over the years, I've often thought it would be convenient to have the keys as class properties, particularly when I've had to write custom queries. I know EOUtilities gives you methods to get the primary and foreign keys for an object, but using these are kind of a pain compared to just calling a simple accessor method. Why not just define getter methods in the class implementation for the primary and foreign keys that you really need to access via Java? You can implement them using the EOUtilities methods. Doing so would avoid the potential problems caused by setting them to be class properties. Aloha, Art ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
using primary and foreign keys as class properties
Hi everyone, I recall reading in some of the early Apple WebObjects documentation that it's a huge terrible thing to mark your foreign and primary keys as class properties (e.g. check the little diamond in EOModeler so that your generated classes give you setters and getters to access them directly). Over the years, I've often thought it would be convenient to have the keys as class properties, particularly when I've had to write custom queries. I know EOUtilities gives you methods to get the primary and foreign keys for an object, but using these are kind of a pain compared to just calling a simple accessor method. I've actually set keys as class properties a few times, but whenever a strange EOF exception cropped up, this was the first thing I always changed back (in a rather superstitious, paranoid way) for fear that somehow having the keys as class properties was giving EOF a fit. I started thinking about it again the other day for some reason, and frankly I can't think of any reason it should have an effect on EOF, so I thought I would pose the question to the list. Is having keys as class properties just something that is for some reason considered "bad form" by the early documentation writers at Apple (I recall the same documentation firmly asserting that you never need to do anything outside EOF, but in the real world this isn't always practical when you need to optimize)? Or is there in fact something about having keys as class properties that throws a monkey wrench into EOF at unpredictable times? Thanks in advance for help/discussion. Mark ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to archive@mail-archive.com
