row.id with "L" after upgrading to

[palomar]

I've just updated to 2.5.1 and I found this problem:

Inside my site  have a google map and I need to add an array with several marker;

in my controller I have a simple query with a cycle

def mappa:

    markers=[]

    for row in db().select(db.produttori.ALL):

       markers.append([row.id, row.lat, row.lng])

return dict(markers=XML(*[markers]))

and I obtein ID + L, like this:

[1L, '12.5', '7.6']

so I need to do int(row.id)

In the older version worked well...

s.

[Derek]

If you aren't using google app engine, then that should be okay. However if you are, you shouldn't convert it to an INT because you'll get errors.

The "L" means it's a LONG and not an INT.

[palomar]

why I shouldn't convert it to an INT? It is the ID of my table and I need it as integer (as on the preview version) to send it to my javascript function... 

[Niphlod]

references and id got "upgraded" cause before with high id numbers you could end up with exceptions.

In any case, you're relying on the default formatting as a string of a value .... for whatever value out there, especially if you need to pass it to javascript, always do EXPLICIT conversions in your app code.

[Anthony]

Inside your XML(), you have a list of lists. XML() will ultimately call the __str__ method on each item in it, and the __str__ method of a list calls the __repr__ method of each item in the list. The __repr__ method of long appends an "L" to the integer value. So, as you have discovered, you must first convert the long to an int. Note, if your row ID happens to exceed the maximum int size, the conversion won't do anything, and you'll still get an "L" appended. Another option is to use str(row.id), though that will put quotes around the integer, which you may not want.

Anthony

[palomar]

thanks for your reply!

[Richard Vézina]

Can someone point me out change log... I didn't see this one...

http://web2py.com/init/default/changelog

I think it is not in the change log and it is not acceptable....

Thanks

Richard

On Wed, Jun 19, 2013 at 9:23 AM, palomar <stefa...@gmail.com> wrote:

thanks for your reply!

--
 
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Niphlod]

it's not a major change. You're the one writing programs that are relying on the default serialization instead of defining your own.

[Alan Etkin]

I think it is not in the change log and it is not acceptable....

Hi Richard. Why it is not acceptable? Did the change break a documented feature? How?

Perhaps you want to post an issue in the project page (code.google.com/p/web2py/issues). If you do, please post as much information you have collected about the problem as you can including source code, error tracebacks, OS, db and web2py version, DAL adapter name and the section of the book with the documented feature that is not working.
 

[Richard Vézina]

As explain Simone in case of passing id to javascript it requires refactoring of app... Also it brake silently a javascript plugin integrated manually as a field widget (not a custom widget). I gues I should have a made some test to cover that, but I am still exploring how the best way to manage test in web2py.

But, I don't understand (didn't read search the mailing-list) what was the motivation and the advantage of this change... Was it related to the bigint change talked about several month ago? It was suppose to be default to integer (what it was until now) and option in for bigint...

Richard

--

[Anthony]

Though to be fair, the documentation simply says that id fields are auto-incrementing integers, and for many years, they were just int's on the web2py side, so it probably wasn't reasonable to expect everyone to do int(row.id) everywhere instead of just row.id in anticipation of some possible future change from int's to long's. Anyway, what's done is done, and reverting would break backward compatibility for many newer apps. Shouldn't be too hard to fix in cases where this is an issue.

Anthony

[Massimo Di Pierro]

It was motivated bit the need to support bigint ID fields. This is for relational databases but, most importantly for non-relational ones. For example in mongodb the ID is a long UUID so we must map that into a ID. It comes up a long integer.

Yet using int instead of long was a problem also when bigint is not used in relational databases, in those cases where many records are added and removed. The ID may grow much more than the number of records you store.

Massimo

[Richard Vézina]

I can manage this no problem, my only concern is how it could have pass under the radar like that. I am less active on mailing-list the last week so I don't read much email... But if you search the mailing-list, you will get almost notting about long...

Richard

[Derek]

But in Python, isn't an int's size unlimited? I didn't think it was mapped to a platform int...

[Niphlod]

>>> import sys
>>> sys.maxint
9223372036854775807
>>> int(sys.maxint +1)
9223372036854775808L
>>> int(sys.maxint)
9223372036854775807