Inconsistency in field naming rules

Posted by tbergman on 19-Apr-2016 11:52

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

OpenEdge Development - Forum

All Replies

Posted by Brian K. Maher on 19-Apr-2016 11:54

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

Posted by tbergman on 19-Apr-2016 12:18

I opened a case.
 
Thanks,
 
Tom
 

Posted by Brian K. Maher on 19-Apr-2016 12:21

Tom,

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

Brian

Posted by Laura Stern on 19-Apr-2016 12:55

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

Posted by marian.edu on 19-Apr-2016 13:14

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 :(


Posted by gus on 19-Apr-2016 13:20

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".

Posted by Brian K. Maher on 19-Apr-2016 13:21

I have submitted bug number PSC00346838 for this.

Posted by marian.edu on 19-Apr-2016 13:44

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

Posted by Brian K. Maher on 19-Apr-2016 13:56

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

Posted by marian.edu on 19-Apr-2016 14:20

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

Posted by tbergman on 19-Apr-2016 16:06

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
 

Posted by gus on 19-Apr-2016 19:04

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.

Posted by marian.edu on 20-Apr-2016 05:44

[quote user="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.
[/quote]
 
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.

[quote user="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. 
[/quote]
Yeah, if not everyone can be made to stop doing it some error handling could also go a long way :)

Posted by marian.edu on 20-Apr-2016 06:00

[quote user="gus"]

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

[/quote]

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 :)

[quote user="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.

[/quote]

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?

Posted by gus on 20-Apr-2016 08:28

> On Apr 20, 2016, at 7:01 AM, marian.edu wrote:

>

> there is no technical reason to impose same restrictions as for static syntax (the prove is this just works)

sorry i was not being clear. let me try again.

what i meant to say is that the rules for static and dynamic should be the same and static ought to be changed to match the dynamic ones. The dynamic ones work because the names are in quotes. But Laura is the compiler expert and it is not for me to say how hard or practical such a change would be.

Posted by Laura Stern on 20-Apr-2016 10:56

The one thing I just found that does not work is using our special bufHandle::<field-name> syntax to get the value of the field for a dynamic temp-table.  E.g.:

DEF VAR tt AS HANDLE.

DEF VAR bhdl AS HANDLE.

CREATE TEMP-TABLE tt.

tt:ADD-NEW-FIELD("foo()", "Integer").

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

bhdl = tt:DEFAULT-BUFFER-HANDLE.

bhdl:BUFFER-CREATE().

MESSAGE bhdl::foo() VIEW-AS ALERT-BOX. /* You get a runtime error: BUFFER-FIELD foo was not found */

If I had made the name "foo(s)", that last line (with bhdl::foo(s)) will not even compile.

Posted by marian.edu on 20-Apr-2016 11:52

Indeed Laura,


we’re aware of this ‘limitation’ but I for one am not bothered by this ‘inconsistency’… there are a few things different when working dynamically compared to the static approach so I don’t see why having consistent naming rules between them is considered such a big deal.

I don’t have any interest in making a feature request for neither support for:
- function alike fields in short notation field access: ttHandle::functionField()
- function alike fields in static temp table definition: def temp-table tt field “functionField()” as char.

If any of those can be implemented might be of interest for others, will certainly not bother me, my only concern is imposing naming restriction on dynamic temp-table fields just to fix this inconsistency. If the bug description is something like "using parentheses (or keywords) in field names on temp-table definition should be supported as for dynamic temp-table” then I have no problem with it (not interested in having it fix either though), if you make it sound more like “using parentheses (or keywords) in field name on add-new-field method of temp-table should throw error” then I just hope it will never get higher on your todo list :(
 
 
Marian Edu

Acorn IT 
+40 740 036 212

Posted by Laura Stern on 20-Apr-2016 13:23

Keywords like "character" ARE allowed - even in a statically defined table - much to my surprise!

Posted by Tim Kuehn on 20-Apr-2016 13:28

[quote user="Laura Stern"] Keywords like "character" ARE allowed - even in a statically defined table - much to my surprise! [/quote]

Unfortunately "transaction" is not a legal TT field name, and that led to some inconsistent TT field names. :(

This thread is closed