Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
--
___
pmapper-users mailing list
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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 pmapper-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
Very useful! -- View this message in context: http://pmapper-users-p-mapper-users-mailing-list.993774.n3.nabble.com/pmapper-users-PMapper5-PM-RESULT-FIELDS-order-not-observed-tp4025638p4025642.html Sent from the pmapper-users -- p.mapper users mailing list mailing list archive at Nabble.com. -- 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 pmapper-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
Re: [pmapper-users] PMapper5 : PM_RESULT_FIELDS order not observed
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
pmapper-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pmapper-users
