O$5 - $loadcols - loading list values without 'Set Current List'

[Bastiaan Olij]

Hey Michael,

This is the trade off we will always face. The easier you make a
language, the harder you make it for that language to do what it needs
to do, the more overhead you create.
It is offset by faster and faster machines.

I use the "slow" method here almost exclusively. There are very few
places in my code where the performance hit outweighs the readability of
my code and the speed at which I can write and maintain bug free code by
using a more flexible and robust notation.

While in Omnis Classic days we would often define a list from a file
class and as a result generally have all the columns there in a fixed
order (as its near impossible to reorder them), in Studio I rarely find
this to be the case. Even something as simple as adding a column to a
schema class, I add it in a logical position so the schema is easier to
read and understand, and leave it up to the way I build my queries to
make sure that the order of the columns in the database is irrelevant.

If I would have to ensure the column order is predetermined for code to
work I would have to check all the code that uses a specific table or
list if a column gets introduce, a column becomes unused and needs to be
removed or I want to leave out certain columns, I would have to spend a
lot of time checking and testing code unnecessary.

Also loading additional columns into a list just so some piece of
central code works because it requires certain columns to be in a
certain order would waste precious bandwidth and may end up wasting more
time then I save by shaving a few ms off a loop.

That all said, when speed is require, it is good to know which functions
can wring out a bit of extra time:)

Cheers,

Bas

P.S. that all said, there is one things in which Omnis has taken a nasty
step backwards here. When you define columns in a list through
$cols.$add or a schema class, they become case sensitive while columns
defined through $define(..) and thus either bound to file classes or
variables are case insensitive.
This cost us dearly when we moved from datafile code to SQL. The amount
of code that broke when we changed over lists that were defined from
file classes to schema classes just because we hadn't been very caring
about using the right case with column names in the past was staggering.

Even now I often run into code mysteriously failing without error just
because historically we have a few mixed case column names or because
we've had all uppercase column names for years but Postgres returns
columns in lowercase when you leave it up to the DAM to add columns to
an undefined list on a fetch (yes you can use double quotes to force
case here).

On 13/03/2015 7:24 am, EurOmnis 2015 wrote:
> I didn't know that…
>
> perhaps at EurOmnis 2015 then. :)
>
>
>  
> Mike Matthews, Finance Manager, OmnisWorld.org
>
> Organisers of EurOmnis Conferences
> phone: +44(0)7973 306790 | web: omnisworld.org | email: info at omnisworld,org
>
>>  
>>
>> Also keep in mind performance if that is important to you. I cover this in my notation session at EurOmnis but...
>>
>> Calculate variable as iList.column_name 
>> 	is one of the slowest forms of accessing a list column
>> Calculate variable as iList.Cn 
>> 	where n is the column number is faster, but you need to know the column number
>> Do iList.$loadcols(,,,field)
>> 	is fastest, but again you need to know the column position (the example accesses the 4th column in the list)
>>  
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>
>


-- 
Kindest Regards,

Bastiaan Olij
e-mail: bastiaan at basenlily.me
web: http://www.basenlily.me
Skype: Mux213
http://www.linkedin.com/in/bastiaanolij