according to the coldfusion docs SerializeJSON converts Dates to strings which can easily be parsed by JavaScript Date objects.
I just serialized a query and JavaScript could not parse the Date columns because the name of the month was serialized local specfic returning Mai, what is not understood by JavaScript. Javascript only accepts english month names. Do I now - as I just did - have to replace the local specific month name manually with it's english translation to easily parse the string to a JavaScript Date object?
Best,
Bernhard
You could try and deal with this on the server by using setLocale('en_us') to force English language versions of your query when serialised - not ideal but it might get the job done. I think this can be set per request. See info here: http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7fa3.html
Hope that helps.
This answer to another question suggests that perhaps you could use datejs and then use the appropriate localization to parse your strings natively rather than in English.
I have a solution
In the coldfusion administrator add this -Duser.language=en -Duser.region=US to the JVM agruments. (And restart the service) You tell the JVM engine not to use the machine locale but to use the 'normal' english locale.
When you use SerializeJSON after the change it will generate dates with the enlish month names.
I haven't found any unwanted side effects with this change.
Related
I have a Python script which collects data and sends it to my MySQL table.
I noticed that the "Cost" sometimes is 0,95 which results in 0 in my table since my table use "0.95" instead of "0,95".
I assume the best solution is to convert the , to . in my Python script by using:
variable.replace(",", ".")
However, couldn't one solution be to change format in my MySQL table? So that I store numbers in this format:
1100
0,95
0,1
150000
My Django Model
cost = models.DecimalField(max_digits=10, decimal_places=4, default=None)
Any feedback on how to best solve this issue?
Thanks
Your first instinct is correct: convert the "unusual" (comma-decimal) input into the standard format that MySQL used by default (dot-decimal) at the first point where you receive it.
there's lots of ways to write numbers
Be careful, though that you don't get stung by people using commas as thousands separators like "3,203,907.23", or the European form "3.203.907,23", the Swiss "3'203'907,23' or even this form, which is widely used in India: "32,03,907.71" (yes, I did mean to type only two digits there!)
To make your life easier, the rule for currencies is relatively simple:
where a dot or comma is followed by only two digits at the end of the string, that character is acting as the decimal separator.
Once you know which is the decimal separator, you can safely remove all other non-digits from the string, change the decimal separator you found to . then use any standard library string-to-number conversion.
Storage format isn't presentation format
Yes, you can tell MySQL to use comma as its decimal separator, but doing that will break so much of your code - including the parts of the framework that read from the database and expect dot-decimal numbers - that you'll regret doing it that way very quickly...
There's a general principle at work here: you should do your data storage and processing using a format that is easy to process, interchangeable with other systems, and understood by other software developers.
Consider what happens if you need to allow a different framework to access your MySQL database to generate reports... whoever develops that software (and it may be you) will be glad that the numbers are all stored the way numbers are "always" stored in databases.
Convert on the way in, re-convert on the way out
Where you need to accept input in a different format, convert that input into your standardised format as early as possible.
When you need to use an output format, do the conversion to that format as late as possible.
The idea is to keep as much of your system "unexceptional" as possible. A programmer who has to remember what numeric format will in force at the time when a given method is called is not a happy programmer.
P.S.
The option you're talking about in MySQL is an example of this pattern: it doesn't change how numeric data is stored. All that changes is how you pass numbers to MySQL and how it presents them back to you.
I'm using Screaming Frog as a way to extract data from a Json generated from an URL.
The Json generated is this form :
{"ville":[{"codePostal":"13009","ville":"VAUFREGE","popin":"ouverturePopin","zoneLivraison":"1300913982","url":""},{"codePostal":"13009","ville":"LES BAUMETTES","popin":"ouverturePopin","zoneLivraison":"1300913989","url":""},{"codePostal":"13009","ville":"MARSEILLE 9EME ARRON","popin":"ouverturePopin","zoneLivraison":"1300913209","url":""}]}
I'm using this regex in Custom > Extraction in Screaming Frog as a way to extract the values of "codePostal".
"codePostal":".*?"
Problem is it doesn't extract anything.
When I test my regex in regex101, it seems correct.
Do you have any clue about what is wrong ?
Thanks.
Regards.
Have you tried to save the output to understand what ScreamingFrog sees? It doesn't matter - not at the beginning - whether your RegEx works.
That said, don't forget that SF is a Java based tool hence it is the engine used by the reg ex, so make sure you test your regular expressions with the correct dialect.
You need to specify group extractors enclosed in parentheses. For instance in your example, you need to have ("codePostal":".*?") as extractor.
In addition if you simply want to extract the value, you could use the following instead.
"codePostal":"(.*?)"
It's not a problem with your Regular Expression. It seems to be that the problem is with the Content Type. ScreamingFrog isn't properly reading application/JSON content types for scraping. Hopefully they will fix this bug.
I am writing pdxInstances to GemFire using the sequence: rabbitmq => springxd => gemfire.
If I put this JSON into rabbitmq {'ID':11,'value':5}, value appears as a byte value in GemFire. If I put {'ID':11,'value':500}, value appears as a word and if I put {'ID':11,'value':50000} it appears as an Integer.
A problem arises when I query data from GemFire and order them. For example, if I use a query such as select * from /my_region order by value it fails, saying it cannot compare a byte with a word (or byte with an integer).
Is there any way to declare the data type in JSON? Or any other method to get rid of this problem?
To add a bit of insight into this problem... in reviewing GemFire/Geode source code, it would seem it is not possible to configure the desired value type and override GemFire/Geode's default behavior, which can be seen in JSONFormatter.setNumberField(..).
I will not explain how GemFire/Geode involves the JSONFormatter during a Region.put(key, value) operation as it is rather involved and beyond the scope of this discussion.
However, one could argue that the problem is not necessarily with the JSONFormatter class, since storing a numeric value in a byte is more efficient than storing the value in an integer, especially when the value would indeed fit into a byte. Therefore, the problem is really that the Comparator used in the Query processor should be able to compare numeric values in the same type family (byte, short, int, long), upcasting where appropriate.
If you feel so inclined, feel free to file a JIRA ticket in the Apache Geode JIRA repository at https://issues.apache.org/jira/browse/GEODE-72?jql=project%20%3D%20GEODE
Note, Apache Geode is the open source "core" of Pivotal GemFire now. See the Apache Geode website for more details.
Cheers!
Your best bet would be to take care of this with a custom module or a groovy script. You can either write a custom module in Java to do the conversion and then upload the custom module into SpringXD, then you could reference your custom module like any other processor. Or you could write a script in Groovy and pass the incoming data through a transform processor.
http://docs.spring.io/spring-xd/docs/current/reference/html/#processors
The actual conversion probably won't be too tricky, but will vary depending on which method you use. The stream creation would look something like this when you're done.
stream create --name myRabbitStream --definition "rabbit | my-custom-module | gemfire-json-server etc....."
stream create --name myRabbitStream --definition "rabbit | transform --script=file:/transform.groovy | gemfire-json-server etc...."
It seems like you have your source and sink modules set up just fine, so all you need to do is get your processor module setup to do the conversion and you should be all set.
I'm using the MarkLogic 7 REST API to build an AngularJS application on top of an XML document database. My documents are in NEWSML-G2 format. I've configured custom query options to return only the title and the creation date for each document that matches the search string. The problem is this.
I have a title element in my XML.
<nitf version="-//IPTC//DTD NITF 3.6//EN" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:newzmeta="http://newz.nl/metadata/" xmlns="http://iptc.org/std/NITF/2006-10-18/">
<head>
<title newz:origin="Generated" xmlns:newz="http://newz.nl/">Test Article</title>
....
</nitf>
In my custom query options, I've used the following line.
<extract-metadata>
<qname elem-ns="http://iptc.org/std/NITF/2006-10-18/" elem-name="title"/>
....
</extract-metadata>
Now, the problem is that when I hit the REST interface to make a query and ask for results in JSON format, I get the following in the response
"metadata":[{"{http://iptc.org/std/NITF/2006-10-18/}title":"Obama assumes the office of the President of the United States","metadata-type":"element"},{" {http://iptc.org/std/nar/2006-10-01/}firstCreated":"2009-01-20T05:00:09","metadata-type":"element"}]
How do I retrieve the title value on the UI side? I get a syntax error if I ask for
result.metadata.{http://iptc.org/std/NITF/2006-10-18/}title
Is there a way specifically to access this value, or to somehow change the name of the element that's returned from the MarkLogic side?
You can do this:
result.metadata.['{http://iptc.org/std/NITF/2006-10-18/}title']
The bracket notation is used to access properties whose names are not valid JavaScript identifiers, preventing you from using the dot notation.
For completeness, an alternative approach would be to write and install a transform for the search response that generates either metadata elements in the empty namespace or a JSON representation that's tuned to your requirements.
But, the simplest way is just to use the bracket notation as Dave suggests.
If I wanted to save a contact form submission to the database, how can I insert the form scope in as the submission? It's been some time since I used Coldfusion.
The contact forms vary depending on what part of the site it was submitted from, so it needs to scale and handle a form with 5 fields or one with 10 fields. I just want to store the data in a blob table.
Most space efficient way and least complicated to turn back into original shape is using serializeJSON. After that, you can use something like key:value|key:value, or XML representation of your struct.
Cfwddx is also an alternative.
I don't know that there is a way to store a native structure into a database, but have you thought about using JSON to represent your object as key-pair values and then parsing it into a native structure after retrieving it from the database?
There are tags/functions out there that will help you with the encoding and decoding into JSON:
cfJSON Tag
CF8 Serialize JSON
CF8 Deserialize JSON
If you can't normalize the form fields into proper table(s), you can try storing them:
in XML (SQL Server supports XML pretty well), or
in JSON (in a plain varchar field), or
ObjectLoad() & ObjectSave() (CF9 only) to store as blob.
IIRC there are ways to get object load/save functionality in pre-CF9 by tapping into Java. http://www.riaforge.org/ or http://cflib.org/ might have it.