Subject | RE: [IBO] FieldName in query with joins and aliases 4.7 bevahes different than 4 |
---|---|
Author | Jason Wharton |
Post date | 2006-12-01T18:05:23Z |
While we are newly taking into consideration the relation alias becoming a
part of the name of columns, this is the best time to openly discuss all the
options of how we reference columns. I believe the way I have chosen to do
things is both flexible and accurate (specific).
Here's some questions to ask:
When there is a column alias is it appropriate to ignore the underlying
table it is associated to?
And, if the underlying table has an alias also, what do you do with the
column alias?
Here is how it currently is in the 4.7 beta:
RelName = Underlying relation name (or blank)
SQLName = Underlying column name (or blank)
RelAliasName = relation alias or the underlying relation name (or blank)
AliasName = column alias or the underlying field name (never blank)
FieldName = AliasName (never blank)
FullFieldName = RelAliasName + '.' + FieldName (never blank) (may not have
relation prefix)
FullSQLName = RelName + '.' + SQLName (or blank) (always has relation prefix
when not blank)
BestFieldName = FullFieldName OR FieldName (depends on if more than one
relation are in the row of columns)(not in the query itself, but in the
output columns)
In many places in the code I have IBO check for a field by name match on
FullFieldName and if a match is not obtained there I will seek a match based
on the FullSQLName if it is different from the FullFieldName. Thus, this
will influence what property settings are picked up from the stringlist
based settings. If you want a property setting to only apply to a specific
column then use the relation alias with the column alias and it pinpoints
that setting only to that specific column. Otherwise, more general settings
may get picked up. The only downside I can see to this level of flexibility
is isolating a column's settings against values bleeding in from settings
that match on its underlying table (RelName) or field (SQLName) names. This
may require some special work and planning, and I'm certain will cause some
unwary developers some frustration when they fail to keep all their ducks in
a row.
Comments?
Jason Wharton
part of the name of columns, this is the best time to openly discuss all the
options of how we reference columns. I believe the way I have chosen to do
things is both flexible and accurate (specific).
Here's some questions to ask:
When there is a column alias is it appropriate to ignore the underlying
table it is associated to?
And, if the underlying table has an alias also, what do you do with the
column alias?
Here is how it currently is in the 4.7 beta:
RelName = Underlying relation name (or blank)
SQLName = Underlying column name (or blank)
RelAliasName = relation alias or the underlying relation name (or blank)
AliasName = column alias or the underlying field name (never blank)
FieldName = AliasName (never blank)
FullFieldName = RelAliasName + '.' + FieldName (never blank) (may not have
relation prefix)
FullSQLName = RelName + '.' + SQLName (or blank) (always has relation prefix
when not blank)
BestFieldName = FullFieldName OR FieldName (depends on if more than one
relation are in the row of columns)(not in the query itself, but in the
output columns)
In many places in the code I have IBO check for a field by name match on
FullFieldName and if a match is not obtained there I will seek a match based
on the FullSQLName if it is different from the FullFieldName. Thus, this
will influence what property settings are picked up from the stringlist
based settings. If you want a property setting to only apply to a specific
column then use the relation alias with the column alias and it pinpoints
that setting only to that specific column. Otherwise, more general settings
may get picked up. The only downside I can see to this level of flexibility
is isolating a column's settings against values bleeding in from settings
that match on its underlying table (RelName) or field (SQLName) names. This
may require some special work and planning, and I'm certain will cause some
unwary developers some frustration when they fail to keep all their ducks in
a row.
Comments?
Jason Wharton