Entity Framework 6 database creation defaults to MVCC now:
Default transaction isolation level is changed to READ_COMMITTED_SNAPSHOT for databases created using Code First, potentially allowing for more scalability and fewer deadlocks. -- http://entityframework.codeplex.com/wikipage?title=specs
On related news:
Want to see an SQL Server DBA nerdgasm'd? Let him/her use Postgresql, it's an RDBMS (that like Oracle) on which the supported concurrency model is MVCC, so you'll get fewer deadlocks on your database:
http://www.youtube.com/watch?v=Rl_-lKxSBm4
Is your database OOP-deprived? See the demo of inheritance using Postgresql on the video above
Microsoft uses Postgresql too, we know Microsoft bought Skype. Skype uses Postgresql
Instagram uses Postgresql too
Saturday, April 6, 2013
Friday, March 15, 2013
AngularJS code for the day...
...have no code at all:
Darn, HTML should be bolted with model from the get-go.
Live code: http://jsfiddle.net/Jpk7x/35/
Manually manipulating DOM elements makes me remember this classic physicist joke:
"It would be a poor thing to be an atom in a universe without
physicists. A physicist is an atom's way of knowing about atoms"
What physicists are to atom, front-end developers are to HTML.
"It would be a poor thing to be an HTML in a universe without
front-end developers. A front-end developer is an HTML’s way of making itself dynamic"
Poor us, the unsuspecting slaves of HTML, we think we are the master of them, but in fact it's the other way around. For non-clientside-mvc-mvvm-using front-end developers, we still have to manually manipulate DOM with our jQuery / document.getElementByBlah skills
Note: Try the jsfiddle example above on HTML5-capable browser only, e.g. Chrome
input type=range is rendered as slider on HTML5-capable browser.
If a browser doesn't recognize range, you can use other slider tags, Wijmo slider for example. Wijmo's AngularJS slider is just as code-less as its HTML5-cousin range:
http://demo.componentone.com/wijmo/using-angular/index.html
<div ng-app ng-init="r=128; g=128; b=128;">
<div class="block" style="background-color: rgb({{r}}, {{g}}, {{b}});"></div>
<input type="range" min="0" max="255" step="1" ng-model="r">
<input type="range" min="0" max="255" step="1" ng-model="g">
<input type="range" min="0" max="255" step="1" ng-model="b">
<p>Drag the sliders</p>
R: {{r}}<br/>
G: {{g}}<br/>
B: {{b}}<br/>
</div>
Darn, HTML should be bolted with model from the get-go.
Live code: http://jsfiddle.net/Jpk7x/35/
Manually manipulating DOM elements makes me remember this classic physicist joke:
"It would be a poor thing to be an atom in a universe without
physicists. A physicist is an atom's way of knowing about atoms"
What physicists are to atom, front-end developers are to HTML.
"It would be a poor thing to be an HTML in a universe without
front-end developers. A front-end developer is an HTML’s way of making itself dynamic"
Poor us, the unsuspecting slaves of HTML, we think we are the master of them, but in fact it's the other way around. For non-clientside-mvc-mvvm-using front-end developers, we still have to manually manipulate DOM with our jQuery / document.getElementByBlah skills
Note: Try the jsfiddle example above on HTML5-capable browser only, e.g. Chrome
input type=range is rendered as slider on HTML5-capable browser.
If a browser doesn't recognize range, you can use other slider tags, Wijmo slider for example. Wijmo's AngularJS slider is just as code-less as its HTML5-cousin range:
http://demo.componentone.com/wijmo/using-angular/index.html
Monday, February 25, 2013
Cargo Cult Programming with COALESCE
I notice one query that do this:
select sum(coalesce(qty,0))from sample; |
Yes, this would result to null:
select 1 + 2 + null as total;
However, like with most things in life, NULL interpretation in SQL is not symmetrical, given the values above and materializing it to rows:
insert into sample(item,qty) values('keyboard',1);insert into sample(item,qty) values('mouse',2);insert into sample(item,qty) values('cpu',null); |
This query would not yield null:
select sum(qty) as totalfrom sample; |
That would result to sum of 3, not null.
And given a table with no rows, which of the following would report a value of 0 when there's no rows?
create table table_with_no_row(item varchar(50) not null,qty int);select sum( coalesce(qty, 0) ) as grand_totalfrom table_with_no_row;select coalesce( sum(qty), 0 ) as grand_totalfrom table_with_no_row; |
Surprise! Ok not so surprising to some, it's the latter that will yield 0. The first one will yield null, despite having coalesce too
Another good use of coalesce:
select h.order_id, h.order_date, coalesce(sum(d.qty),0) as totalfrom order_header hleft join order_detail d on d.order_id = h.order_idgroup by h.order_id ,h.order_date;select h.order_id, h.order_date, sum(coalesce(d.qty,0)) as totalfrom order_header hleft join order_detail d on d.order_id = h.order_idgroup by h.order_id ,h.order_date; |
Both queries above would yield the same result.
order_id order_date total----------- ---------- -----------1 1940-10-09 22 1956-10-28 0(2 row(s) affected) |
Given they have the same result, why should we opt for sum( coalesce(d.qty,0) )?
Aggregate functions automatically discard null values, hence it's superfluous to put a coalesce inside an aggregate function. Placing a coalesce inside an aggregate hurts performance, as coalesce is repeatedly executed on every row. I once optimized a very slow query just by removing the COALESCE inside of SUM and placing it outside of SUM, way back long time ago since the dawn of time
Cargo Cult Programming is rearing its ugly head. Cargo Cult Programming is wreaking havoc on database performance
Happy Computing! ツ
Sunday, February 24, 2013
Implementing a database admin interface in AngularJS is a breeze
Implementing a database interface(think phpPgAdmin) via web with semantics (read: HTML5) and AngularJS is a walk in the park
View:
Controller and models:
Works on Chrome
Live code: http://jsfiddle.net/5WvWP/
View:
<div ng-repeat='p in personTable'>
{{p.label }} <input ng-model='person[p.fieldName]' type='{{p.type}}' />
</div>
<div>Favorite Number via slider: <input ng-model='person.FavoriteNumber' type='range'/></div>
<hr/>
{{person}}
Controller and models:
function Something($scope) {
$scope.personTable = [
{ fieldName: 'Lastname', type : 'text' },
{ fieldName: 'Firstname', type : 'text' },
{ fieldName: 'Birthday', type : 'date' },
{ fieldName: 'FavoriteNumber', type : 'number', label: 'Favorite #' }
];
for(var fieldIndex in $scope.personTable) {
var field = $scope.personTable[fieldIndex];
if (field.label == undefined)
field.label = field.fieldName;
};
$scope.person = { Lastname : 'Lennon', Firstname : 'John', Birthday: '1940-10-01', FavoriteNumber : 9 };
}
Works on Chrome
Live code: http://jsfiddle.net/5WvWP/
Please RTFM
Got my fair share of RTFM last week. I've written a REST-adhering AngularJS code for deletions. I'd written it this way:
But the record is not deleted.
I assumed the second parameter is a data parameter, I should thought early that second parameter has many options. Another lesson learned, aside from not reading the AngularJS doc, handling errors should be our second nature, the errors provided by ServiceStack helps a lot for debugging why the particular method for RESTful deletion is not routed to its proper service method.
Upon adding .error callback, lot of guessworks were avoided on why there's a 405 error, which naturally led me to read AngularJS doc. $http delete has a config parameter, the second parameter is not directly a data paramater
To correctly pass the data parameter with AngularJS:
Obligatory xkcd reference: http://xkcd.com/293/
$http.delete('/departments', { Id: d.DepartmentId }).success(function (responseData) {
alert('ok');
});
But the record is not deleted.
I assumed the second parameter is a data parameter, I should thought early that second parameter has many options. Another lesson learned, aside from not reading the AngularJS doc, handling errors should be our second nature, the errors provided by ServiceStack helps a lot for debugging why the particular method for RESTful deletion is not routed to its proper service method.
Upon adding .error callback, lot of guessworks were avoided on why there's a 405 error, which naturally led me to read AngularJS doc. $http delete has a config parameter, the second parameter is not directly a data paramater
To correctly pass the data parameter with AngularJS:
$http.delete('/departments', { params : { Id: d.DepartmentId } }).success(function (responseData) {
alert('ok');
}).error(function(data, status, headers, config) {
console.log(data);
alert(data.ResponseStatus.Message);
alert(status);
});
Obligatory xkcd reference: http://xkcd.com/293/
Tuesday, February 12, 2013
Got multitude of jQuery approaches to offer? Thanks but no thanks, I got AngularJS
Just when I thought I already unearthed all the possible techniques for obtaining the value from a dropdown selection:
Apparently, I lack imagination, I saw this code from a dropdown change event:
Something is fundamentally wrong on that last code but I can't quite put my finger on it. Oh darn, now I remember.. that attr('value') is so leaking the abstraction!
Getting the value of something is a staple in our everyday job, hence we should give it a first-class treatment, give it a proper abstraction, i.e. we should be able to use this: $(this).val(), not a hodge-podge of stringly-typed voodoo magic that $('#Country > :selected').attr('value') is
I'm not gonna remember all the possible jQuery combinations the mankind has ever known just to obtain that elusive value from a dropdown control, what other approaches should I remember?
Ok, thanks, but no thanks, I got AngularJS, I just have to remember this: $scope.CountryCode
The question I posed above is rhetorical, but you can probably show other jQuery approaches for getting the value from a dropdown change event that I missed, be it a shorter code or long code, seriously.
Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. -- Edsger Dijkstra
$('#CountryCode').change(function () {
// Why use this?
// alert($('option:selected', '#CountryCode').val());
// Or this?
// alert($('option:selected', $(this)).val());
// When this will suffice:
alert($(this).val());
});
Apparently, I lack imagination, I saw this code from a dropdown change event:
$('#CountryCode > :selected').attr('value');
Something is fundamentally wrong on that last code but I can't quite put my finger on it. Oh darn, now I remember.. that attr('value') is so leaking the abstraction!
Getting the value of something is a staple in our everyday job, hence we should give it a first-class treatment, give it a proper abstraction, i.e. we should be able to use this: $(this).val(), not a hodge-podge of stringly-typed voodoo magic that $('#Country > :selected').attr('value') is
I'm not gonna remember all the possible jQuery combinations the mankind has ever known just to obtain that elusive value from a dropdown control, what other approaches should I remember?
Ok, thanks, but no thanks, I got AngularJS, I just have to remember this: $scope.CountryCode
The question I posed above is rhetorical, but you can probably show other jQuery approaches for getting the value from a dropdown change event that I missed, be it a shorter code or long code, seriously.
Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. -- Edsger Dijkstra
Monday, February 11, 2013
Javascript mental gymnastic
var s =
'(function() {\
return function(n){\
return n * n;\
};\
})()';
var f = eval(s);
console.log(f);
alert(f(3));
Subscribe to:
Posts (Atom)