|
|
That sounds like the SOTW on tranquilizers
|
|
|
|
|
Exactly
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
no thank you. it's just noise to me.
I do like techno, EDM, etc. but this is just crap IMHO.
|
|
|
|
|
|
|
Nice ones!
Not quite my current mood (yet ), but I do love such stuff from time to time.
|
|
|
|
|
|
It's a torrid affair. I've begun using JSON to back entity objects and after doing so I don't think I'm ever going back.
Jeez it's cool tho.
I'm addicted. Maybe I need help.
This is just exciting.
At the risk of dropping some code here:
an example of one (read-only in this case, but adding writing is doable too)
public abstract class TmdbEntity : IEquatable<TmdbEntity>
{
protected TmdbEntity(IDictionary<string, object> json)
{
Json = json ?? throw new ArgumentNullException(nameof(json));
}
public IDictionary<string, object> Json { get; protected set; }
protected T GetField<T>(string name,T @default=default(T))
{
object o;
if (Json.TryGetValue(name, out o) && o is T)
return (T)o;
return @default;
}
public bool Equals(TmdbEntity rhs)
{
if (ReferenceEquals(this, rhs))
return true;
if (ReferenceEquals(rhs, null))
return false;
return ReferenceEquals(Json, rhs.Json);
}
public override bool Equals(object obj)
{
return Equals(obj as TmdbEntity);
}
public static bool operator==(TmdbEntity lhs, TmdbEntity rhs)
{
return lhs.Equals(rhs);
}
public static bool operator!=(TmdbEntity lhs, TmdbEntity rhs)
{
return !lhs.Equals(rhs);
}
public override int GetHashCode()
{
var jo = Json as JsonObject;
if(null!=jo)
{
jo.BaseDictionary.GetHashCode();
}
return Json.GetHashCode();
}
}
Then in your derived classes:
public class TmdbLanguage : TmdbEntity
{
public TmdbLanguage(IDictionary<string,object> json) : base(json)
{
}
public string Name => GetField<string>("name");
public string EnglishName => GetField<string>("english_name");
public string Iso => GetField<string>("iso_639_1");
}
Then on any entity you can also get the Json property to get all of the actual data for your object as one unit, which you can then query on. This makes it better than traditional entities that consume and toss or otherwise hide the underlying data structure, frankly. It's not only more "pure" to back your state with the actual data you got, it's also easier to query on it or update it. By query it i mean do like "JsonObject.Select(myEntity.Json,"$.id")" if you want or "myEntity.Id"
So, do I need help?
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, definitively
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
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.
|
|
|
|