Quantcast

[pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Raffaele Morelli
Hi,

there's an issue with PM_RESULT_FIELDS and the specified order of fields.

No matter what is specified in PM_RESULT_FIELDS, fields order follows postgis
table fields order.

Can you confirm this behaviour?

--
« Nunc est bibendum, nunc pede libero pulsanda tellus »

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Armin Burger-2
yes, I guess this was always the way how it worked aslo in older
versions. It's not just for Postgis but also shapefile layers etc.

The change to make it behave as you expected is to modify the
lib/query/query.php file at line 229 replacing the 4 subsequent lines
with the following ones:
     foreach ($resultFields as $fld) {
         if (array_key_exists($fld, $recIn)) {
             $rec[$fld] = $recIn[$fld];
         }
     }

Maybe a bit of testing would be needed but it could be changed in the
main code to always work like that, I agree that it seems more logic...

armin


On 10/13/2014 01:47 PM, Raffaele Morelli wrote:
> Hi,
>
> there's an issue with PM_RESULT_FIELDS and the specified order of fields.
>
> No matter what is specified in PM_RESULT_FIELDS, fields order follows postgis
> table fields order.
>
> Can you confirm this behaviour?
>

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Raffaele Morelli
On 14/10/14 at 12:32am, Armin Burger wrote:

> yes, I guess this was always the way how it worked aslo in older
> versions. It's not just for Postgis but also shapefile layers etc.
>
> The change to make it behave as you expected is to modify the
> lib/query/query.php file at line 229 replacing the 4 subsequent lines
> with the following ones:
>      foreach ($resultFields as $fld) {
>          if (array_key_exists($fld, $recIn)) {
>              $rec[$fld] = $recIn[$fld];
>          }
>      }
>
> Maybe a bit of testing would be needed but it could be changed in the
> main code to always work like that, I agree that it seems more logic...
>
> armin

Tested a little and works smoothly. IMHO it should be committed because when
dealing with query results it's really useful to rearrange fields order and left
db query untouched (even more with shapefile's dbf, I guess).

eg. I would prefer to put hyperlink stuff in the last columns

/raffaele

--
« Nunc est bibendum, nunc pede libero pulsanda tellus »

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Armin Burger-2
On 10/14/2014 07:50 AM, Raffaele Morelli wrote:

> On 14/10/14 at 12:32am, Armin Burger wrote:
>> yes, I guess this was always the way how it worked aslo in older
>> versions. It's not just for Postgis but also shapefile layers etc.
>>
>> The change to make it behave as you expected is to modify the
>> lib/query/query.php file at line 229 replacing the 4 subsequent lines
>> with the following ones:
>>       foreach ($resultFields as $fld) {
>>           if (array_key_exists($fld, $recIn)) {
>>               $rec[$fld] = $recIn[$fld];
>>           }
>>       }
>>
>> Maybe a bit of testing would be needed but it could be changed in the
>> main code to always work like that, I agree that it seems more logic...
>>
>> armin
>
> Tested a little and works smoothly. IMHO it should be committed because when
> dealing with query results it's really useful to rearrange fields order and left
> db query untouched (even more with shapefile's dbf, I guess).

OK, committed to svn trunk

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

gioza
Very useful!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Thomas
In reply to this post by Armin Burger-2
Hi,

I think it should be better to use "isset($recIn[$fld])" instead of
"array_key_exists($fld, $recIn)" by considering performance.


Le 14/10/2014 19:10, Armin Burger a écrit :

> On 10/14/2014 07:50 AM, Raffaele Morelli wrote:
>> On 14/10/14 at 12:32am, Armin Burger wrote:
>>> yes, I guess this was always the way how it worked aslo in older
>>> versions. It's not just for Postgis but also shapefile layers etc.
>>>
>>> The change to make it behave as you expected is to modify the
>>> lib/query/query.php file at line 229 replacing the 4 subsequent lines
>>> with the following ones:
>>>        foreach ($resultFields as $fld) {
>>>            if (array_key_exists($fld, $recIn)) {
>>>                $rec[$fld] = $recIn[$fld];
>>>            }
>>>        }
>>>
>>> Maybe a bit of testing would be needed but it could be changed in the
>>> main code to always work like that, I agree that it seems more logic...
>>>
>>> armin
>> Tested a little and works smoothly. IMHO it should be committed because when
>> dealing with query results it's really useful to rearrange fields order and left
>> db query untouched (even more with shapefile's dbf, I guess).
> OK, committed to svn trunk
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> pmapper-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/pmapper-users
>
>


------------------------------------------------------------------------------
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Armin Burger
ok, I can change that, though I guess the the performance gain will be
likely quite small in real world situations. Lets just hope no field
names will be ever called "null" then... ;-)

armin

On 10/29/2014 12:26 PM, Thomas RAFFIN wrote:

> Hi,
>
> I think it should be better to use "isset($recIn[$fld])" instead of
> "array_key_exists($fld, $recIn)" by considering performance.
>
>
> Le 14/10/2014 19:10, Armin Burger a écrit :
>> On 10/14/2014 07:50 AM, Raffaele Morelli wrote:
>>> On 14/10/14 at 12:32am, Armin Burger wrote:
>>>> yes, I guess this was always the way how it worked aslo in older
>>>> versions. It's not just for Postgis but also shapefile layers etc.
>>>>
>>>> The change to make it behave as you expected is to modify the
>>>> lib/query/query.php file at line 229 replacing the 4 subsequent lines
>>>> with the following ones:
>>>>         foreach ($resultFields as $fld) {
>>>>             if (array_key_exists($fld, $recIn)) {
>>>>                 $rec[$fld] = $recIn[$fld];
>>>>             }
>>>>         }
>>>>
>>>> Maybe a bit of testing would be needed but it could be changed in the
>>>> main code to always work like that, I agree that it seems more logic...
>>>>
>>>> armin
>>> Tested a little and works smoothly. IMHO it should be committed because when
>>> dealing with query results it's really useful to rearrange fields order and left
>>> db query untouched (even more with shapefile's dbf, I guess).
>> OK, committed to svn trunk
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> pmapper-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/pmapper-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> pmapper-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/pmapper-users
>

------------------------------------------------------------------------------
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed

Raffaele Morelli
On 29/10/14 at 07:07pm, Armin Burger wrote:
> ok, I can change that, though I guess the the performance gain will be
> likely quite small in real world situations. Lets just hope no field
> names will be ever called "null" then... ;-)

on the positive side, you could use "null" for very secret stuff
field.
:-)

>
> armin
>
> On 10/29/2014 12:26 PM, Thomas RAFFIN wrote:
> > Hi,
> >
> > I think it should be better to use "isset($recIn[$fld])" instead of
> > "array_key_exists($fld, $recIn)" by considering performance.
> >
> >

--
« Nunc est bibendum, nunc pede libero pulsanda tellus »

------------------------------------------------------------------------------
_______________________________________________
pmapper-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Loading...