|
Couldnt you add a new string field?
datestring leave elephanting format untouched
datestring_standard unindexed aux data "should" not bother stuffy DBAs (in my dreams)
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I'm not sure how that would fix the actual problem.
We propogate a date string into the database, and use it that way (other stored procs ar casting it to a datetime, and the app is expecting it as a string value, so we're right and truly f*cked). We can't change it because of the inevitable side effects it would cause. This is a massive system, and in point of fact, this is just one of the DOZENS of reasons I want to do a complete rewrite (app and data).
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Add a column to the DB? He'd need permission in triplicate from The Donald himself, plus an allocation from Congress of a few billion dollars ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Adding a column to the db could be done dynamically in the stored proc. This would mitigate the need to add instructions to our deployment script to change the table.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: This crap shoulda been fixed YEARS ago.
Ah, the mantra of the free soul that hasn't been crushed by the cogs of "I don't give a sh*t anymore."
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
#realJSOP wrote: This crap shoulda been fixed YEARS ago.
"Technical debt".
If there was ever a great example to use as a definition, this is it.
|
|
|
|
|
Do you prefer to always wrap the JSON in an outer object?
For example, a call to a credit card processor to get supported credit cards. Do you prefer simply the array returned:
[
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
or the array wrapped in an outer "object":
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
]
}
If one or the other, why?
Personally, I'm leaning toward the second form, which forces the Javascript writer to at least initially use the PaymentMethods tag:
let ccs = resp.PaymentMethods;
Which I think improves code readability. It's also more maintainable IMO, as perhaps other tags at some point might be added -- one simple thing that comes to mind is a flag that indicates whether ACH is supported (mind you, these are all concrete examples of the general question of JSON tags):
{
"PaymentMethods": [
"AM",
"DI",
"EB",
"EP",
"MC",
"VI"
],
"SupportsACH": true
}
Using an outer object wrapper doesn't break the code if additional JSON elements are added later.
So...thoughts?
Marc
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Kind of an obvious reply:
If there's more than one dimension to the data then I want the outer objects.
Otherwise, although I prefer it to be clean (data really doesn't include a 'header'), so long as I know it's coming it's no big deal.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
The outer object is important because even if currently there aren't any extra data items, such as the ACH you mentioned, yet, inevitably there will be and this could cause a failure in the simpler case while being handled smoothly with an outer object wrapping things up nicely.
Having said that, many past members of projects I have worked on didn't get the memo...
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Forogar wrote: inevitably there will be and this could cause a failure in the simpler case while being handled smoothly with an outer object wrapping things up nicely.
My thoughts as well.
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
2nd one for sure, helps with deserialization as well. You end up with a better formed object model.
|
|
|
|
|
No-brainer. 2nd as you say.
Another reason is: another day, another person may look at your data or code. That other person might be yourself, in a galaxy far far away. I usually like to spend good time on naming things cleanly.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I go with the second version as well and for the reasons stated. We all know that the only thing constant is change so the second form is a no brainer!
I do all my own stunts, but never intentionally!
JaxCoder.com
|
|
|
|
|
I think the first example is not valid JSON, there again I am not a JSON expert.
Definitely go with the second one!
Edit] turns out I am wrong about the not valid statement I made -JSON[^]
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 3-Apr-19 9:54am.
|
|
|
|
|
GuyThiebaut wrote: turns out I am wrong about the not valid statement I made
Given I copied the response from the actual service call....
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Just because a service call works, doesn't mean it is correct. Many internet services incorrectly implement the rfc (dns, smtp, many more...).
|
|
|
|
|
I also thought that a valid JSON document has to have a root object. Is it not the case then?
Anyways, I prefer the first one because it's shorter, and since it is a response, you should already well know what's gonna be in it: exactly the data requested.
However, I have had some issues with the Java JSON library being unable to parse arrays by themselves. As a result, the way it's implemented in production right now (as suggested by StackOverflow :P ) is as follows:
- JSON comes in on the network, looking like the first example you gave
- Function checks if it starts with '[' and finds that yes, it does
- So it appends some string around the received text, making it look like the second one
- JSON lib parses this. The returned JsonObject's only JsonArray member is saved, the rest discarded
- Prod code gets this JsonArray back to do whatever
Fun times!
"I don't think about dying. It is the last thing I want to do. " - theoldfool
|
|
|
|
|
The outer object is redundant. I prefer the array when it is an array.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I prefer the road that is more and more "less travelled" - the right way, which is the 2nd option.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
Not to mention the newest crop of "programmers" that we're starting to see...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
#realJSOP wrote: newest crop of "programmers" that we're starting to see...
"Starting", he said...
Never lose your sense of humor, JSOP.
|
|
|
|
|
Also it very much depends on how you organise your server side code. Do you serialise lists or dictionary of objects.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Second, of course. Unless I try to go bonkers, then it is this:
[{
"PropertySet": [{
"Id": "1",
"Name": "fancyProperty",
"Type": "String",
"IsArray": "true"
}],
"ValueSet": [{
"PropertySetId": "1",
"Value": "AM"
},
{
"PropertySetId": "1",
"Value": "DI"
},
{
"PropertySetId": "1",
"Value": "EB"
},
{
"PropertySetId": "1",
"Value": "EP"
},
{
"PropertySetId": "1",
"Value": "MC"
},
{
"PropertySetId": "1",
"Value": "VI"
}
]
}]
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
|