Inconsistency in field naming rules - Forum - OpenEdge Development - Progress Community

Inconsistency in field naming rules

 Forum

Inconsistency in field naming rules

  • I just found that the naming rules for dynamic temp-table fields differ from those for static temp-table fields.

    This will not compile:

    DEFINE TEMP-TABLE foo

    FIELD Publisher(s) as CHARACTER.

    This compiles (and works) just fine:

    hTT:ADD-NEW-FIELD("Publisher(s)", "char", 0, "x(8)", "", "Publisher(s)", "Publisher(s)").

    Has anyone else noticed this? Is it a bug? Feature?

     

    Thanks,

     

    Tom

  • Tom,
     
    I would consider it to be a bug.  Not sure if development would agree.
     
    Brian

  • I opened a case.
     
    Thanks,
     
    Tom
     
  • Tom,

    I have grabbed that case & will let you know what they say.

    Brian

  • To allay the suspense... I agree - it is a bug.

  • hmm… I would say a ‘harmless’ one, and for backward compatibility sake hope this will still work :)

    DEF VAR tt AS HANDLE.

    CREATE TEMP-TABLE tt.

    tt:ADD-NEW-FIELD('character', 'character').

    tt:TEMP-TABLE-PREPARE('mytt').

    MESSAGE tt:DEFAULT-BUFFER-HANDLE:BUFFER-FIELD(1):NAME VIEW-AS ALERT-BOX.

    FINALLY:
        DELETE OBJECT tt NO-ERROR.
    END.


    we’re using that ‘feature’ for both jdbc driver and strongloop (node.js) connector… mainly as field ‘alias’, if the ‘fix’ is to throw error on add-new-field if field name is a Progress keyword this will break our alias feature :(


  • also,

    in SQL there is the concept of "delimited identifiers" (i.e names enclosed in quotes) to get around problems like that and also names that conflict with keywords.

    Using that idea, you would say

    DEFINE TEMP-TABLE "find"

    FIELD "Publisher(s)" as CHARACTER.

    and then you could say find "find" where "Publisher(s)" = "Laura".

  • I have submitted bug number PSC00346838 for this.

  • have no problem if compiler could be extended to allow keywords in static data access if table/fields’s names are quoted… but broking something that works, agree might have been a hidden gem for most, just because was discovered and found of no use by someone else shouldn’t probably be top priority but have to agree Im a bit puzzled on how bugs gets categorised there :(

    something that works ok, although maybe not by-design, is hardly a bug… a bug is when something doesn’t do what it was designed to do

    beside, static and dynamic data access is totally different… for dynamic data access the compiler doesn’t help much and can’t get confused as in case of static access, hence why having same restrictions if there is nothing that requires that?


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Marian,
     
    I would say that if using parentheses in table field names was not part of the design (which it was not) then that is indeed a bug simply because it was NOT part of the design.
     
    Kind of like if someone attaches a retaining clip to the center console of a car and uses it to hold a large, heavy item that goes vertically through the sunroof which then suffers a catastrophic failure when the vehicle is under high speed.  The manufacturer didn’t actively PREVENT the installation of such a retaining clip but the installation and usage of such a clip was certainly never part of the cars design.
     
    <smile>
     
    Brian

  • Hey Brian, guess that depends on the driver after all… I can happily drive at full speed with quite large items on that console :)

    Running a statement like `select count(*), min(balance) from customer` through our driver will just return a record having two fields with names that seems not to be supported ‘by-design’ although it perfectly works and there is no mention about naming restrictions on add-new-field method in existing documentation nor that it ever was anything like that as far as I know of.

    Beside, in his initial post, Tom didn’t bring forward any use case that will help qualify this as a bug… even if using fields with parentheses would hurt someone when doing it, just stop doing that thing and pain will go away :)


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • Very reasonable –Ask for use case. There is one. After all, I didn’t just find this by random chance. J
     
    I have an application that needs to write large amounts of data into a .Net DataTable (and later this data goes into a SQL Database). The class that does this has to be able to accept any temp-table with any number of fields. It creates a .Net data table, examines the temp-table schema and creates a schema in the DataTable, then it has to copy all the temp-table data to the DataTable. This is sometimes millions of rows, a hundred or more columns.
     
    Taking a fully dynamic approach worked well but was a little slower than I liked. By dynamic I mean a dynamic query, then looping through every field, assigning the value of the field to the correct DataTable column.
     
    I found that by generating a progress program, with a static temp-table definition for all of the fields, a for each on the static table, and static assignments of all the field values, the performance was three times faster. So I write out some code. Then run it. Then delete it.
     
    By now you’ve realized how I found the problem. One of the programs that used this class had a dynamic temp-table with a field named “Publisher(s)” which caused the generated program to fail to compile on the fly.
     
    I know, a bit bizarre, but there you have it. And yes, an easy answer is to stop doing that, which is exactly what I did with the offending program.
     
    Tom
     
  • the problem here is a general langauage syntax one - you want to name a vairable somethignthat looks like a functioncall.

    this problem comes up in all programming languages. well mst of them anyhow. you wrote something that looks like def var x(i) as character. but variable names are nt allowed to have "(" or ")" characters in them and the compiler thinks this is a function call. Granted, the dynamic names do not follow the same rules and that is wrong.

    Like it or not, you have to follow the naming rules. and those should be the same for static and dynamic names.

    In this case, the error is that the dynamic rules are too lax and should have been more restrictive to match the static ones.

    If we make them more restrictive, no one will be happy.

  • tbergman
     
    By now you’ve realized how I found the problem. One of the programs that used this class had a dynamic temp-table with a field named “Publisher(s)” which caused the generated program to fail to compile on the fly.

     
    Right, but that has nothing to do with dynamic temp-table definition anymore... you turned that into static one so naming restrictions applies to void confusing the compiler.

    tbergman
    I know, a bit bizarre, but there you have it. And yes, an easy answer is to stop doing that, which is exactly what I did with the offending program. 

    Yeah, if not everyone can be made to stop doing it some error handling could also go a long way :)

  • gus

    the problem here is a general langauage syntax one - you want to name a vairable somethignthat looks like a functioncall.

    I have no desire to do such a thing, do understand the challenges of language parsing and won't advocate for having variable names that looks like function calls especially in an already ambiguous syntax as our good old 4gl :)

    gus

    Granted, the dynamic names do not follow the same rules and that is wrong.

    Like it or not, you have to follow the naming rules. and those should be the same for static and dynamic names.

    I still don't see why this is so wrong, there is no technical reason to impose same restrictions as for static syntax (the prove is this just works)... it's not like a armed gun or anything that you can hurt others with, it's just a special one that one can use to shoot himself in the foot - hope those will be launched soon on idiegogo so we can way for Darwin to make the selection :)

    It's true I can't do mytt::count(*) as that will also confuse the compiler but mytt:default-buffer-handle:buffer-field('count(*)') works just fine... you haven't heard me complaining for not being able to use the shortcut version did you? :)

    Point is, this simply works as-is and for me adding restrictions just to make the dynamic handling 'consistent' with the static one is like forbidding birds to fly because mammals can't... oh wait, let me try a language I'm not very familiar with, from the business perspective what will be the justification to cover the development cost for 'fixing' that huge bug walking around free?