DB in upgoer

A

ACID

Up-goer
  • ATOMICITY A group of queries can happen and can be started and if it is stopped without being done it will not change the database.
  • CONSISTENCY A group of queries should be able to go from one place where the database is not broken to another place where the database is not broken.
  • ISOLATION A group of queries should not be changed by other groups of queries.
  • DURABILITY If the database breaks and stops, the database should be able to be started without changing what is written in it.

C

Client

Up-goer

Databases don’t just tell the world everything. They need to be asked for something. They might be asked to do something, like change the stuff inside it or just tell someone something. Something asks them to do these things. This thing which is asking the database to do something is called the “client”.

Extended version

Column

Up-goer

This is like the name of one piece of the stuff the table has in each row. In this table, the things under the words “First One” are all in the first part of the row. They are both in the same “column”.

If you move over any of the things under “First One”, you will see them change color. I hope this will make it easy to see how a column works.

First One Second Two
Row 1 Row 1, Column 1 Row 1, Column 2
Row 2 Row 2, Column 1 Row 2, Column 2
Row 3 Row 3, Column 1 Row 3, Column 2

COMMIT

Up-goer

When a database is given a lot of things to do, this will be the last thing it is told so that it knows to do all of those things except when there is a problem.

See also

Transaction

Cursor

Up-goer

Sometimes, when you ask a database to do something, you want it to give you something short. Sometimes this is a problem because there may be a lot of stuff which it wants to give you. A cursor is a way to keep your place when looking through a lot of this stuff. That way you can look at a small piece at a time.

Extended version

This is an anagram which stands for Current Set Of Records. When dealing with databases which return a large amount of data, sometimes it is too much to handle all at once. For example, while a database might have no problem returning millions of rows, sometimes that will cause the program asking for the data to freeze (millions of records is often not small). Ideally the program should only handle a small part of the data at once. If you think of what was returned as a book, the cursor would be the page that the program is reading.

Database

Up-goer

A short way of explaining this is that it is something a computer can use to hold stuff (like numbers, words, or even pictures) so that it is easy to find. Sometimes one of these will be simple, and sometimes it will not. Most of the time when people use this word, they mean something which will hold stuff in things called “tables”.

Extended version

Databases can be anything, the only thing they have to do is be structured in some way (though not necessarily a good way). They can even be pieces of paper which are kept in a filing cabinet, but this would mean that it would take a very long time for the computer to find what it is looking for.

Delete

Up-goer

A type of thing you can tell a database to do when you want it to get rid of some of its stuff.

Date

Up-goer

the date. This will look like year-month-day. So it March 7, 2012 would be 2012-03-07.

Extended version

A database will have an internal concept of a date. This allows it to do things like date-based arithmetic, so that the client

DATETIME

Up-goer

This is one of the three things a database uses to think about time. It tells people the time of day and the date at the same time.

Deadlock

Up-goer

(Please read about locks first)

Sometimes, when there are many locks in the database and it is told to do more than one thing at the same time. Sometimes it is told to do things which both need to hold locks, but the locks can’t be let go because of other locks. For example one query will lock table A while it tries to write on table B, another query might be locking table B while it waits for the lock on table A to end. In this case, both table A and B will reach a point where both queries will not be able to finish because both need to read or write in the other’s locked table. This is a “deadlock”.

Insert

Up-goer

a type of thing you can tell a database to do if you want it to keep more stuff.

Lock

Up-goer

When something needs to write in the database, the database knows that this can cause problems if there are other attempts to write to the same area (a lot of times this means a table, but it can sometimes be only a small piece of a table). To make sure that this doesn’t happen, the database will “lock” that area and make it so that nothing else can get in and read or write at the same time. Sometimes the lock simply stops other queries (a query is some words given to the database which tells it to read or write something) from writing to the same place, and sometimes it stops other queries from even getting to that area.

Select

Up-goer

A type of thing you can tell a database to do. It is for when you want the database to tell you about the stuff it keeps. It should never change that stuff though.

Sequence

Up-goer

this is a thing that a database holds. It is a number, and you can tell the database to add one to it.
It helps keep databases clean because only one person at a time can add to it. It helps to think about when people are told to pick a number and stand in line. If two people could get the same number they would be angry. Instead, everyone gets their own number, and so everyone can buy lunch.

Time

Up-goer

the time of day. It uses 24 hours, and it includes seconds.

Timestamp

Up-goer

This is a big number which stands for how long it has been since Jan. 1, 1970.

Transaction

Up-goer

A big group of things a database is told to do. Most of the time they will happen one after another, and if the database thinks that any one of them will break, none of them will happen.

Extended version

Transactions are ways that databases keep themselves and their data safe. If a group of queries says “insert into table A and then insert into table B” it can be bad if table B causes an error and table A is changed.

A very simple example might be a bank database being told, “Transfer $100 into Frank’s checking account from Frank’s savings account.” This might turn into two instructions in the database: “Add $100 to Frank’s checking account. Subtract $100 from Frank’s savings account.” If Frank didn’t have $100 in his savings account, it would be a problem if the first instruction (add money to checking) went through but the second failed (subtract money from savings). Frank probably wouldn’t be too unhappy about it, but the bank would have a problem: they just gave Frank $100 for free!

Update

Up-goer

A type of thing you can tell a database to do when you want it to change the stuff it keeps.

Posted in Uncategorized | Leave a comment

Something which needed to be explained to a client which seemed worth keeping.

This is an up-goer 5 explanation of database locking. I kept the words “database” and “query” because those are too ubiquitous, and, presumably, if you’re asking about deadlocks, you at least have heard of a database.

Basically a lock is:

When something needs to write in the database, the database knows that this can cause problems if there are other attempts to write to the same area (usually this means a table or a row of a table). To make sure that this doesn’t happen, the database will “lock” that area and make it so that nothing else can get in and read or write at the same time. Sometimes the lock simply stops other queries (a query is some words given to the database which tells it to read or write something) from writing to the same place, and sometimes it stops other queries from even getting to that area.

A deadlock is:

Sometimes, when there are many locks in the database and more than one query is given at the same time, the different queries stop each other. One query will lock table A while it tries to write on table B, another query might be locking table B while it waits for the lock on table A to end. In this case, both table A and B will reach a point where both queries will not be able to finish because both need to read or write in the other’s locked table. This is a “deadlock”.

Posted in Uncategorized | Leave a comment

Open graph req’s

So… trying to get an open graph link to allow for an inline video player is annoying. It turns out you need to define a very specific set of OG properties:

<html>
<head>
    <title>theophoruspress.com</title>
    <meta property="og:site_name" content="$$domain$$" />
    <meta property="og:title" content="$$title$$" />
    <meta property="og:type" content="video"/>
    <meta property="fb:app_id" content="$$facebook ao ID$$">
    <meta property="og:description" content="$$description$$" />
    <meta property="og:url" content="http://$$domain$$/$$canonical URL$$" />
    <meta property="og:image" content="http://$$domain$$/$$path to icon$$" />
    <!-- Not sure if swf is 100% necessary, right now I'm simply adding this for quick ref. -->
    <meta property="og:video" content="http://$$domain$$/$$path to video$$.swf">
    <!-- This does need to reflect the content type of the above video -->
    <meta property="og:video:type" content="application/x-shockwave-flash">    
    <meta property="og:video:secure_url" content="https://$$domain$$/$$path to video$$" />
    <meta property="og:video:width" content="$$width$$">
    <meta property="og:video:height" content="$$height$$">
</head>
<body>
</body>
</html>
Posted in Scripts | Tagged | Leave a comment

Old data shouldn’t count

There is a new pizza restaurant in my town. Not that we needed one: we had at least five already, but now we have a sixth. This one is less than a half mile from two other pizza locations (and arguably the two best), and I do wonder what the owners are thinking. They must think that they have something truly excellent if they plan on pulling that off, especially in New Jersey, a state where everyone has a strong opinion about what makes a good pie.
Continue reading

Posted in Business | Tagged , , , , | 1 Comment

C# has no mixin.

Recently I came across a lovely bit of engineering by my favorite nemesis: Sitecore.

So, I have two controls, one is a Sitecore.UI.WebControls.HtmlControl and the other is a System.UI.WebControls.HtmlControl. Now, because they both serve the same purpose, have the same name, and have remarkably similar namespaces, you would imagine that the Sitecore one was an extension of the System one, right? Unfortunately not.
Continue reading

Posted in Languages, Sitecore, Worst Practices | Tagged , , , , , , | Leave a comment