Heh, heh. Belt and suspenders and duct tape. In the taxonomy of code smells, this one is "The Smell of Fear."

bstorer:

ligne:

parsing that wretched CSV format using split isn't generally a good idea, but since google themselves specify that the response won't contain any stray commas (only integers and latitude/longitude specifiers), that's not a problem.

You fool! You can't just rely on them to tell you it won't have any stray commas! Hasn't this thread taught you anything? You have to expect all programs you interact with to fail in impossible ways.

 

 

very good point.  google employs some pretty smart people, so it's only a matter of time before they invent some *completely new numbers*.  i can't wait for that, it'll be amazing.  even if i do have to re-write all my code.

 

 

pitchingchris:

What if you get a partial response ?  No matter who it is, you almost never trust input from external sources without validating it. Suppose google decides to make a change 2 years from now ?   Is your program going to break then ? 

 For most of the API, you can specify a specific version of the API to use, then at least the "what if Google changes it" stance is largely gone. I don't see this example specifying the version though, which I believe does mean "the latest stable version," which could theoretically start putting quotes around the numbers. Though I don't know why they would randomly do that, since you only need quotes if you have embedded commas and commas are never going to make sense as part of a latitude, longitude or altitude unless they decide to randomly switch to using commas as decimal separators. Which would make no sense to switch a style once you have one as you get no benefit and break external code at the same time.

They might plausibly add some more fields, though they would hopefully do that at the end and not break this code. And you should verify external sources (the partial result in particular seems plausible), though it's very common to not do so in example code.

 Good points though in the context of non-example code.

bstorer:

ligne:

parsing that wretched CSV format using split isn't generally a good idea, but since google themselves specify that the response won't contain any stray commas (only integers and latitude/longitude specifiers), that's not a problem.

You fool! You can't just rely on them to tell you it won't have any stray commas! Hasn't this thread taught you anything? You have to expect all programs you interact with to fail in impossible ways.

I wonder what it would look like when you get localized data for those countries that swapped the decimal-point for the decimal-comma. I still remember SAP R/3 barfing when someone tried to batch-upload a tab-delimited file that was actually a copy-pasted file from excel... on a PC which had been erroneously setup with the Spanish (Spain) locale. SAP didn't like seeing 35,00 instead of 35.00, nice.

Anyway, nice discussion on whether or not the LIMIT 1 was a WTF... especially as it seems that rowid is similar to the oid column in PostgreSQL. Those never repeat, and can identify anything, tables, schemas, whatever. I might see .fetchonerow() as something practical as a shortcut, but LIMIT 1 on a PK/UNIQUE search has all the usefullness of a "WHERE 1" ... or even "WHERE 1=1".

danixdefcon5:

especially as it seems that rowid is similar to the oid column in PostgreSQL. Those never repeat, and can identify anything, tables, schemas, whatever.

Not only is it similar to oid, but you can refer to it using oid:

http://www.sqlite.org/autoinc.html:

You can access the ROWID of an SQLite table using one the special column names ROWID, _ROWID_, or OID.

danixdefcon5:

Anyway, nice discussion on whether or not the LIMIT 1 was a WTF... especially as it seems that rowid is similar to the oid column in PostgreSQL. Those never repeat, and can identify anything, tables, schemas, whatever.

oids are not row identifiers in postgres.  They can repeat which is why you have to do regular vacuum maintenance to prevent database corruption (one of the many WTFs of postgres).  Additionally, relying on the oid instead of using a sequence is just sloppy altogether and should be avoided.