Always Get Better

Posts Tagged ‘data types’

Using DateTime in the Play! Framework

Sunday, May 20th, 2012

Which data type should you use for time information on your Java models? The Date class is mostly deprecated, pushing us into the direction of the heavyweight Calendar class. Storing the milliseconds since Epoch in a Long is both database-friendly and easy to perform math on and convert at runtime. But if you really want a good experience, you are using Joda Time.

Joda Time is built into the Play! Framework, and there really is no excuse to use anything else. But when it comes to saving dates in your JPA Models, there is a big “gotcha” in that there is no default type converter to move a DateTime object into and out of the database. Oops.

But that can be fixed with an annotation in your model, like this:

@Type(type="org.joda.time.contrib.hibernate.PersistentDateTime")
public DateTime created;

Unfortunately, Play does not ship with Hibernate support for the DateTime object. So to make this work you need to include the Joda-Time-Hibernate library in your dependencies.yml file:


require:
- play
- joda-time -> joda-time-hibernate 1.3

After updating the dependencies file, run the play deps –sync command to pull in the libraries from maven. Your models will now save their date and time into MySQL, and your programming experience will be smooth as silk – at least as far as time-based functionality is concerned.

Azure Table Storage vs Azure SQL

Sunday, April 24th, 2011

There is a lot of debate among newcomers to Azure whether to use Azure SQL or file-based Table Storage for data persistence. Azure itself does not make the differences very clear, so let’s take a closer look at each option and try to understand the implications of each.

Azure SQL
Azure SQL is very similar to SQL Server Express. It is meant as a replacement for SQL Server Standard and Enterprise, but the feature set is not there yet. Reporting services, in particular, are in community technology preview (CTP) phase and at the time of writing are not ready for prime time.

Programmatically, Azure SQL is very similar to SQL in existing web applications; any ODBC classes you already wrote will work directly on Azure with no changes.

Size and cost are the major limitations with Azure SQL in its current incarnation. The largest supported data size is 50GB which runs for $499/month. Any databases larger than 50GB would need to be split across multiple instances – this requires knowledge of sharing at the application level and is not easy surgery to perform.

Table Storage
Table storage uses a key-value pair to retrieve data stored on Azure’s disk system, similar to the way memcache and MySQL work together to provide the requested data at fast speeds. Each storage container supports 100TB of data at incredibly cheap ($0.15/GB) rates.

Working with table storage involves accessing them directly from your application differently than you may be accustomed to with SQL. Going all-in ties you to the Azure platform – which is probably not a problem if you’re already developing for Azure as you will likely be trying to squeeze every ounce of performance out of all areas of the platform anyway.

Table storage does not support foreign key references, joins, or any of the other SQL-stuff we usually use. It is up to the programmer to compensate by making wide de-normalized tables and build their lists in memory. If you’re already building clustered applications, this is not a new design pattern as developers typically want to cache data in this manner.

Besides the larger space limits, table storage affords us automatic failover. Microsoft’s SLA guarantees we will always be able to access the data, and this is accomplished by replicating everything across at least three nodes. Compared to self-managing replication and failover with the SQL service, this is a huge advantage as it keeps the complexity out of our hands.

Difference in Evolution
If Azure SQL seems somewhat stunted compared to Table Storage, it’s not an accident: it is a newcomer who was not planned during the original construction of the Azure platform. Microsoft carefully considered the high-availabilty trends used for application development and found that the NoSQL way would most easily scale to their platform. Developer outrage prompted the company to develop Azure SQL, and its service offerings are improving rapidly.

Depending on your storage needs, your course of action may be to store as much data for cheap in Table Storage, and use SQL to index everything. Searching the SQL database will be incredibly fast, and can be done in parallel with any loads against persistent tables – everybody wins.

Display Class Objects in CheckedListBox

Sunday, March 28th, 2010

If you want to use anything more complex than a list of strings in a ListBox, you’re in luck because the control accepts all types of objects.

Custom Objects (Blog Posts) Displayed in a CheckListBox

Custom Objects (Blog Posts) Displayed in a CheckListBox

In this case, I want to display a list of posts found in a blog. Blog is a class which contains Posts, an array of Post classes. To start, I created the CheckedListBox in the form designer, and I add the posts to it like this:

clbPages.Items.AddRange(_blog.Posts);

If I do nothing else, the ListBox will call the Post’s ToString() method and will display as:

Post
Post
Post
Post

We have two options for displaying this correctly:

1. Override the ToString() method. I don’t recommend doing this because ToString() is much more appropriately used in a debugging context.

2. Add a string converter: This will automatically convert each post object to a usable string when called by an object like a ListBox. ListBox uses Convert.ToString() – this uses that converter more appropriately. ToString() should only be used as a fallback.

<pre>
// Use System for the Type object
using System;
// Use ComponentModel for the TypeConvert base class
using System.ComponentModel;

namespace SiteAssistant.Blog
{
    /// <summary>
    /// Converts a post into a list-friendly string, for checkbox lists
    /// </summary>
    class PostConverter : TypeConverter
    {
        /// <summary>
        /// Indicates whether the Post can be converted to a destination type
        /// </summary>
        /// <remarks>
        /// We only support conversions to STRING at present
        /// </remarks>
        /// <param name="context"></param>
        /// <param name="destinationType"></param>
        /// <returns></returns>
        public override bool CanConvertTo(ITypeDescriptorContext context,
            Type destinationType)
        {
            if (destinationType == typeof(string))
                return true;
            else
                return base.CanConvertTo(context, destinationType);
        }

        /// <summary>
        /// Converts the post to the destination type. If the destination
        /// type is not supported, the base Conversion is applied.
        /// </summary>
        /// <remarks>
        /// We only support converting posts to strings at present.
        /// </remarks>
        /// <param name="context"></param>
        /// <param name="culture"></param>
        /// <param name="value"></param>
        /// <param name="destinationType"></param>
        /// <returns></returns>
        public override object ConvertTo(ITypeDescriptorContext context,
            System.Globalization.CultureInfo culture, object value,
            Type destinationType)
        {
            if (destinationType == typeof(string))
            {
                string text = "";
                Post p = value as Post;
                // Ensure that the Post is not null, avoid errors
                if (null != p)
                {
                    text = p.Title;
                }
                return text;
            }
            else
            {
                return base.ConvertTo(context, culture, value, destinationType);
            }
        }
    }
}
</pre>

The code we write in .NET is like the meat inside a sandwich. The framework is the bread that wraps around our logic and keeps our application together. Our new Posts string converter will be called by the application without us needing to override the Convert function.

It doesn’t happen by magic of course. The final change we have to make is to add information about our conversion function to the posts class:

<pre>
    [System.ComponentModel.TypeConverter(typeof(PostConverter))]
    public class Post
    {
        // Rest of the code goes here
    }
</pre>

That’s all there is to it! Now we can pass a list of Posts to the CheckedListBox and manipulate each item directly. In this application, I will be using this technique to provide the Post object to the text editor with a double-click.

Implementing Lazy Load Using a Proxy Class

Saturday, February 28th, 2009

Lazy load is a design pattern wherein an object is not instantiated until the last possible minute. This is very handy when working with lists of items whose contents are expensive to retrieve from the data store.

There are typically three ways of implementing lazy load:
1. Lazy Initialization – The object is set to null and checked/loaded when data is needed
2. Proxy – A proxy class for the object is created using the same interface as the original class; whenever a property is called, the proxy creates the object and returns the correct data
3. Ghost – The class loads only a partial set of its information until more is needed

Example Situation

In my example situation, we handling a catalogue of artists owned by a fictional record label. For each artist, we will store a name, musical genre, web site address, and number of albums.

UML for Artist Class

UML for Artist Class

Let’s pretend we have thousands of artists on our roster, and we need to print a catalogue containing all of their information. Rather than loading all of that data into memory right away and having to wait until that process is done before we can begin printing, it makes more sense to get a list of how many artists will be printed (so our software knows how many pages to print) but to only load the actual information when we are ready to print it.

The solution is to create an ArtistProxy class. ArtistProxy has an _artist variable who is set to null when it is initialized. Whenever we try to access the artist’s name, web site, etc from ArtistProxy, the class creates an Artist (only if not already done) and returns the property from _artist.

Our print function is never aware of ArtistProxy – as far as it is concerned it only ever deals with Artist. We accomplish this by creating an interface – IArtist – which acts as a contract for both ArtistProxy and Artist. If we add more properties to Artist later on, IArtist will keep us honest by forcing us to also update ArtistProxy.

Artist, ArtistProxy, and IArtist UML Diagram

Artist, ArtistProxy, and IArtist UML Diagram

Now that we understand how our classes relate to each other, it’s time to use them in code:

[source:csharp]
// Our printArtists() function looks something like this.
// Notice how we are unaware whether the artist is
// an actual object, or a whether it is a proxy.
public function printArtists( IArtist [] artistList )
{
foreach ( IArtist artist in artistList )
{
printOneArtist( artist );
}
}

// Implementation of the IArtist interface
public interface IArtist
{
string Name { get; set; }
string Genre { get; set; }
string Website { get; set; }
int getNumberOfAlbums();
}

// Implementation of Artist class
public class Artist : IArtist
{
private int _id;
private string _name;
private string _genre;
private string _website;

public Artist( id )
{
_id = id;
}

public string Name
{
get { return _name; }
set { _name = value; }
}

public string Genre
{
get { return _genre; }
set { _genre = value; }
}

public string Website
{
get { return _website; }
set { _website = value; }
}

public int getNumberOfAlbums()
{
return fictionalDataConnection->getNumberOfAlbums( _id );
}
}

// Implementation of ArtistProxy class
public class ArtistProxy : IArtist
{
private Artist _artist;
private int _id;

public ArtistProxy( id )
{
_artist = null;
_id = id;
}

public string Name
{
get
{
if ( null == _artist ) _artist = new Artist( _id );
return _artist.Name;
}
set
{
if ( null == _artist ) _artist = new Artist( _id );
_artist.Name = value;
}
}

public string Genre
{
get
{
if ( null == _artist ) _artist = new Artist( _id );
return _artist.Genre;
}
set
{
if ( null == _artist ) _artist = new Artist( _id );
_artist.Genre = value;
}
}

public string Website
{
get
{
if ( null == _artist ) _artist = new Artist( _id );
return _artist.Website;
}
set
{
if ( null == _artist ) _artist = new Artist( _id );
_artist.Website = value;
}
}

public int getNumberOfAlbums()
{
if ( null == _artist ) _artist = new Artist( _id );
return _artist.getNumberOfAlbums();
}
}
[/source]

Of course for the sake of convenience a few things are missing from my example:
1. An actual data source
2. Delegates (presumably one would include a ‘LoadArtist’ delegate so the proxy will be able to pass the actual loading of its artist to the data layer)

C#: Using Suffixes to Declare Data Literals

Thursday, May 1st, 2008

This isn’t new, but handy to have.  In order to tell the compiler which data type we’re using, we use suffix notation as follows:

  • Unsigned integer, U: e.g. 34506U
  • Long integer (signed), L: e.g. 5297532L
  • Unsigned long integer, UL: e.g. 30958UL
  • Float, F: e.g. 13.6F
  • Double, D: e.g. 14.3D
  • Decimal, M: e.g. 19.95M