AutoEdge - Discussion - Forum - OpenEdge Architecture - Progress Community
 Forum

AutoEdge - Discussion

  • My point is that with 10.1A this becomes trivial and

    a language built-in so I was guessing that the

    procedure preceded 10.1A and originally contained

    some workaround code to imitate what the built-in now

    does. Then, when you got the built-in, it replaced

    the body of the procedure.

    That is exactly what happened. In the first version (10.0), this procedure generated a long string out of things like date and time, session-handle, IP address and lots of random characters to create a "unique" ID.

    In a second iteration, we had this procedure call an external DLL to get a UUID.

    When the UUIDs became available in the language, we replaced all that stuff with this very simple call. And while it now looks strange to create a wrapper around a single line of code, it made a lot of sense in terms of maintainability back then, and probably is still a good idea now just in case you would ever want to replace this function. Not that I can think of anything more unique than a UUID :P

  • That's what I figured. It is certainly a good design approach for minimizing disruption as new language features are added. My favorite antique example of this in my own code was writing a series of routines that presented various kinds of dialog boxes ... in version 5 or something.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • We have expanded the AutoEdge aspect on OpenEdge Hive a little bit. The main page is here http://www.oehive.org/AutoEdge . In addition to the previous issue tracker, we have added a section on project documentation to provide commentary. You will find the first of these, an annotated version of the Programming and Naming Conventions document here http://www.oehive.org/node/656 .

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Looking over some of the sample code for xxCar.*, I run into a couple of questions about design choices (other than the lack of .cls, of course! ).

    In becar.p:

    • There are two methods, eCarCreatePreTrans and eCarModifyPreTrans. I presume these are separate so that there is a consistent signature pattern for all beXXX.p and in case there needs to be some difference between them, but in this instance the two methods are identical. Would it not have been preferable for one to call the other or both to call some common code?

    • In those same procedures, there is a call to eCarValidation, which is a procedure in becar.p. Why wouldn't this be a method of dacar.p?

    • In those same procedures, there is a call to getCarDesc, which is in the dacar.p superprocedure. Why wouldn't this already be resolved, i.e., de-normalized by the fetch in dacar.p?

    more later ...

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • I agree with this approach. I think it generally is a good idea to try to minimize 'change effects' by abstracting these type of utility statements and wrapping them in self made code. So even if we would have started with OpenEdge 10.1A or later, the GUUID() call would be wrapped.

  • BUG:

    in src/server/autoedge/becustomer.p:

    ASSIGN

    dLicDate = DATE( MONTH(eCustomer.CustomerBirthDate),

    DAY(eCustomer.CustomerBirthDate),

    YEAR(eCustomer.CustomerBirthDate) + dLicYear)

    .

    will not work for people born on Feb 29.

    I've been in other shops that made this mistake, and in one of them it cost ~$20K to fix, plus the reputation hit in the marketplace.

  • BUG:

    in src/server/autoedge/becustomer.p:

    ASSIGN

    dLicDate = DATE(

    MONTH(eCustomer.CustomerBirthDate),

    DAY(eCustomer.CustomerBirthDate),

    YEAR(eCustomer.CustomerBirthDate) + dLicYear)

    .

    will not work for people born on Feb 29.

    I've been in other shops that made this mistake, and

    in one of them it cost ~$20K to fix, plus the

    reputation hit in the marketplace.

    Of course we left such features in the code to see who would be really paying attention

    But good catch. Feel free to post a fixed version

  • But good catch. Feel free to post a fixed version

    I'm doing a code review. Fixing the problem is someone else's responsibility.

  • A couple of things I have noticed in terms of the standards document versus the dictionary which I am wondering if someone would like to comment on.

    1. The standards document indicates that the primary key of every table should be of type integer, but the actual primary keys in the autoedgexx databases are of type character with a format of X(64). Without even looking at the code I can guess that this means the use of a GUID instead of an integer, which seems fine to me, but perhaps is an indication that the standards document should be revised.

    2. The standards document indicates that fields which are foreign keys to another table should have the same name at the key of that table, i.e., so an OF join would work. However, the use of the BaseCode table to serve as a generic holder of codes and descriptions implies that one could not have two such codes in the same table and still keep this naming standard. Consequently, we have Car with BaseCodeStyleID and BaseCodeColorID, among others. This seems perfectly clear, but again it seems that one should either annotate the standards document to indicate this exception or consider some other change.

    Just curious.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Just a thought, but I think if I were to going to revise this application, one of the things I would consider doing is creating a table for the pool of test drive cars which was separate from the pool of the dealer's inventory. Realistically, I believe that a dealer would have only a limited number of cars out of the inventory designated for giving test drives. So, if someone was interested in a blue XYZ, they might get their test drive in a green one, but be able to walk out on the lot and see the blue one. Functions like ASN for incoming cars is definitely related to full inventory, not just cars associated with test drives. Also, there are probably properties of test drive cars that one might want to track, like total miles driven. I would imagine that dealers had rules about how many miles they want to put on a car before it is no longer saleable as new. So, they might put a car into the test drive pool until that limit is approached and then remove it from the pool and/or flag a car with excessive miles that it can no longer be sold as new.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • A couple of things I have noticed in terms of the

    standards document versus the dictionary which I am

    wondering if someone would like to comment on.

    1. The standards document indicates that the primary

    key of every table should be of type integer, but the

    actual primary keys in the autoedgexx databases are

    of type character with a format of X(64). Without

    even looking at the code I can guess that this means

    the use of a GUID instead of an integer, which seems

    fine to me, but perhaps is an indication that the

    standards document should be revised.

    Your guess is correct, we moved to using GUID's during the project so that is probably an oversight in terms of updating the doc.

  • >..... Also, there are probably

    properties of test drive cars that one might want to

    track, like total miles driven. I would imagine

    that dealers had rules about how many miles they

    want to put on a car before it is no longer saleable

    as new. So, they might put a car into the test

    drive pool until that limit is approached and then

    remove it from the pool and/or flag a car with

    excessive miles that it can no longer be sold as new.

    Sure, but don't forget this is only an example app, we're not looking to sell it However, we do have a little flag on the inventory that can be set/un-set to mark a car as available for a test drive or not. Simple I know.

  • Mike, I appreciate that it is only an example, but one of the things which bugs me persistently about most example code is when it is too simple. AutoEdge on the whole certainly isn't that whereas sports was. But, I see no reason not to craft an example with the kind of structures that one would need if one were to flesh it out in to a full application. Aren't you suggesting that people make additions? Well, suppose someone wanted to create a demo inventory module? They would be faced with having to change the dictionary to get a suitable structure, not just additional fields, but changing the structure, thus requiring other parts of the app to be modified in order to accommodate the change. I think it is possible to create data structures which anticipate growth and that this itself is a good lesson in best practice.

    E.g., there is one contact in the dealer. Now, it is reasonable to designate a principal contact in the dealer, but there is certainly more than one person in the dealership that one might wish to contact at various times. One should have a structure which allows associating multiple employees with the dealership and flagging one of these as principal.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • E.g., there is one contact in the dealer. Now, it is

    reasonable to designate a principal contact in the

    dealer, but there is certainly more than one person

    in the dealership that one might wish to contact at

    various times. One should have a structure which

    allows associating multiple employees with the

    dealership and flagging one of these as principal.

    Even though we may not have a 'Principal' flag, there are address details for the dealership, but then there are multiple employees per dealer.

    The question to all these details is how far do you go, before you stop being an example for discussion and knowledge purposes, as opposed to building a complete featured app. It's a balance, and I hope in the main we've got the balance about right.

  • Well, to my taste I would have gone a bit further. Like the inventory thing ... I would have made it two tables. The two tables would have have all of the fields in them that a full-fledged application would have, but the basic structure is there so that, should someone want to do an enhancement, one could merely add a field or two and move forward without having to change anything that is already there. I think most of this is up front work on the schema. One could have a significantly more tables in the schema without making the application significantly more difficult to create, but the resulting application would more closely resemble the structure of a real application.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com