|
okay true, but what i've just done is either a really Good Idea(TM) or a really Bad Idea(TM)
either way, it's cool. Simple, elegant, unobtrusive. But using that many dictionary instances might freak some people out.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: but what i've just done is either a really Good Idea(TM) or a really Bad Idea(TM)
It's actually quite possible to be both at the same time. It all depends on what problems you encounter, or DON'T encounter further down the road.
It's only experience that can tell you what problems you don't encounter.
Personally, unstructured data gives me the shivers.
|
|
|
|
|
Jörgen Andersson wrote: Personally, unstructured data gives me the shivers.
Well, to be fair, JSON is not entirely unstructured, but it is a bit fast and loose.
I've been using it for this TMDb thing i made and hitting it pretty hard just now, and it rocks.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
JSON works well where traditional relation databases lacks. Tree structures.
|
|
|
|
|
that too yeah, but as far as indexing tree structures, i mean, XML can build trees too. It's just that xml isn't implicitly indexed when using most tools.
If you store JSON objects as dictionaries like most programming environments do (using whatever their associative array mechanism is) then their keys are automatically indexed which makes pathfinding through the tree much faster.
makes sense to me. Just use IDs as field names and bob's your uncle.
so i agree.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
But this indexing would depend on the tools used.
Personally I consider JSON and XML to be more or less interchangeable, where XML is the verbose one supporting 2 million use cases you never even knew about.
While JSON is the one being used because people understand it intuitively, and it works.
|
|
|
|
|
Typically even with tools that support it - and many do not, you have to use XML Schema, and then set the indexed key attribute in the schema.
for JSON every fieldname is automatically indexed. that's why they are spec'd as unordered.
it's primarily due to a difference in spec.
in XML element tags are ordered, meaning they must be ordered as presented in the document (they cannot be reordered to make searching faster)
in JSON object fields are unordered, meaning their order can't be relied on which means the system can reorder it as it likes to make searching faster - and every single tool i've ever encountered for JSON does this directly or indirectly)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I do't think I really get the point...
Why not a MongoDB store and use JsonConvert.Deserialize<someclass>(json) and JsonConvert.Serialize(someObject)?
If you want all that flexibility you could use Deserialize<dynamic> or even use ExpandoObjects.
I think you forgot a return statement there
honey the codewitch wrote:
public override int GetHashCode()
{
var jo = Json as JsonObject;
if(null!=jo)
{
RETURN jo.BaseDictionary.GetHashCode();
}
return Json.GetHashCode();
}
|
|
|
|
|
OUCH that's what i get for writing code at 3am
Nice catch. Thanks.
I'm not using MongoDB because it's heavy handed comparatively. This is a few source files.
I can already do dynamic with like
dynamic json = JsonObject.Parse("{\"foo\":\"bar\"}");
Console.WriteLine(json.foo);
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Sander Rossel wrote: use JsonConvert.Deserialize<someclass>(json) and JsonConvert.Serialize(someObject)?
|
|
|
|
|
one source file vs an entire dependency tree.
JsonObject.Parse
JsonObject.WriteTo
same parameters.
no big
coding a json engine is trivial. effing trivial. there's no need to drag around something like mongo if you don't need it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
What are you rambling about, now?
|
|
|
|
|
Json.Deserialize .. isn't that part of mongo? or am i missing something? (i probably am missing something)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
No, it is not.
NuGet Gallery | Newtonsoft.Json 12.0.2[^]
271,290,153 downloads so far. Defacto, industry-standard assembly for working with JSON.
The bloody work has already been done for you. No need to write your own JSON parsers, etc. reinventing the wheel, aren't you?
|
|
|
|
|
Maybe it's newer? It wasn't in the older frameworks except as part of silverlight.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
It has been around since 2011 - not really new.
I think you need to re-educate your self on how to work with JSON and do what most developers do with JSON. Use the library I linked to in the previous post.
|
|
|
|
|
oh you're talking about that 3rd party lib. - sorry, it's late here. I didn't process your entire reply.
again a single source file verses an entire dependency set.
I don't need all those features.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
one .dll. very lightweight.
|
|
|
|
|
one dll for this, and then another dll for that, pretty soon you're talking about real setup.
one little package is how i like it.
i guess i'm old fashioned.
if json was more difficult i'd probably use something 3rd party. but then i have to deal with licenses and other nonsense.
Also i really wanted this tree to backed with the generic versions of IDictionary and IList for a number of reasons.
I'm not sure if NewtonSoft's already does it. I'd have to use it to find out
Furthermore there is the RPC aspect of it, and i don't think that's in Newtonsoft's lib but again i haven't used it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
do your own thing. I was just showing you what the rest of the world does.
|
|
|
|
|
yeah, i mean again, if i had reason to i'd use a 3rd party dll for this. i don't need one in this case is all
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: So, do I need help?
Yes, and you can find it in one of the programming forums. Here, all we recommend is to ditch whatever it is that you are doing, consume copious amounts of alcohol and rewrite this in VB6.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
rewriting it in VB6 would definitely require getting drunk and i don't drink.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Try rewriting and you will start drinking.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
I've already rewritten my JSON engine a couple of times, and I've rewritten my TMDB api twice now. That last one made me want to drink. It's huge.
The first go round i guess was me getting the design straight. I needed to do it, so it wasn't a total loss. Massaging the data from TMDb gets ugly sometimes, so i needed something a bit more flexible on the second go, plus i happened on A Better Way(TM) in the process so that's happy.
Anyway, I love using Json to back the state in my entities. It's a joy to code against. Everything is easy, especially given the realm of data interchange
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|