My job as a developer evangelist for Couchbase means than I work much less with SQL Server than I used to. However, it doesn't mean I don't keep up with it.
In fact, inspired by Couchbase, I decided to try out using SQL Server as a sort of document data store. SQL Server 2016 introduced some interesting new features that make this kinda possible: JSON_VALUE, JSON_QUERY, and JSON_MODIFY.
I set up a "document" table, which is two fields: a guid and an nvarchar(max). This is kinda like a Couchbase bucket: a key and a JSON document to go with it.
I put fairly complex hierarchical documents in these fields, something like:
I say "fairly complex", because representing this in a standard normalized fashion would require at least two tables, foreign keys, constraints, and then data migration and schema migration as the model evolves.
Now, suppose I want to execute a query and find all the document that are "Show=true". With Couchbase and N1QL, I would just use something like "SELECT * FROM `bucket` WHERE show = true".
With SQL Server, there's a little more work. "SELECT t.key, t.doc FROM [table] t WHERE JSON_VALUE(t.SpeakingInfo,'$.Show') = 'true'". Notice that JSON_VALUE is being applied to a text field, and a JSON path is used within JSON_VALUE to get a specific value from within that JSON object.
For this simple project I'm doing, that's all I need. No idea yet what kind of performance level I can expect from JSON_VALUE and more complex JSON paths.
But, this is definitely an example of the kinds of database convergence I've been telling people about. The separations between NoSQL and SQL are becoming less strict, at least in terms of data modeling and querying.
You need to be using SQL Server 2016 or SQL Server Azure to take advantage of the JSON_* functions.
I've recently had to write some ASP Classic. Don't worry, it's not like I'm writing new features, just integrating with old ones. So, since this is an ancient technology, some of this may be old news to you. But much of it was new to me, and I'm a developer with some years of ASP Classic experience.
Most of the stuff I had to do was pretty minor, but one major thing I found interesting was that I had a need to make an HTTP request in ASP classic. This turns out to be not so bad.
The trickiest part was figuring out that I had to explicitly specify the content type, since it apparently doesn't set a default.
If we can run JScript and VBScript with the same ASP Classic page, then guess what, we can use Douglas Crockford's JSON library. It's so perfect and simple, and I wish I came up with it on my own.
That's about 100 times more elegant of a solution than I even expected when I started on this code.
I have a web page on domain A and, say, a Json endpoint on domain B. I would like domain A to make an Ajax request to domain B, but when I try that, I get an error message, as shown here:
Let's explore the jsonp option. Here's a similar request to the one above, except this time it's using jsonp.
It does not raise an error.
The way jsonp works is a little wacky, but the main thing you need to know is that you need to specify a callback function. jQuery handles this automatically on the client side. Here's how I handle it on the server side with ASP.NET MVC using the Mvc.Jsonp package.
Notice three things:
The benefit is that you can now do cross-domain scripting. So far the drawbacks seems to be that:
I'm giving it a shot on Ledger, and seems to be working fine so far.
I've been working a little bit here and there on a mobile app. One thing this app does a lot is use a RESTful API over HTTP, where the results are JSON.
I'm using RestSharp to handle these requests, and RestSharp can automatically serialize Json results into C# object(s), assuming I have C# objects that match.
Well, some of these JSON results can be a little complex. Not terribly complex, mind you, but enough to where it's annoying to create the classes myself. But I thought to myself, maybe there's a tool out there that already does this for me. I googled around and found json2csharp, which is a handy web app that does exactly that.
Well, thanks to Rob Gibbens, I now know that this feature is actually built-in to Visual Studio 2013, and available for 2012 as part of "ASP.NET and Web Tools".
You can see that there are some differences, but these tools get you most of the way there!
Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.