MongoDB Replication is Easy

Posted on August 8, 2010 by Geoff Lane

Database replication with MongoDB is easy to setup. Replication duplicates all of the data from a master to one or more slave instances and allows for safety and quick recovery in case of a problem with your master database. Here is an example of how quick and easy it is to test out replication in MongoDB.

Create a couple of directories for holding your mongo databases.

mkdir master slave

Start by running an instance of the “master” database.

cd master
mongod  --master --dbpath .

Start a new terminal window and continue by running an instance of a “slave” database. This example is running on the same machine as master which is great for testing, but wouldn’t be a good setup if you were really trying to implement replication in a production environment since you would still have a single-point-of-failure in the single server case.

cd slave
mongod --slave --port 27018 --dbpath . --source localhost

And start another terminal window to use as the client

mongo
db.person.save( {name:'Geoff Lane'} )
db.person.save( {name:'Joe Smith'} )
db.person.find()
db.person.save( {name:'Jim Johnson', age: 65} )
db.person.find()

Now kill the master instance in your terminal with Control+C. This simulates the the master server dying.
Lastly connect to the slave instance with a mongo client by specifying the port.

mongo --port 27018
db.person.find()

As you can see, the db.person.find() returns all of the values that were saved in the master list as well which shows that replication is working. One of the other interesting facts is that you can start a slave instance even after the mongod master is already running and has data and all of the data will be replicated over to the slave instance as well. This all works without ever shutting down your mongod master instance. This allows you to add replication after the fact with no downtime.

Posted in Code | Tagged , , | Leave a comment

MongoDB and Java: Find an item by Id

Posted on June 17, 2010 by Geoff Lane

MongoDB is one of a number of new databases that have cropped up lately eschewing SQL. These NoSQL databases provide non-relational models that are suitable for solving different kinds of problems. This camp includes document oriented, tabular and key/value oriented models among others. These non-relational databases are supposed to excel at scalability through parallelization and replication but sometimes (although not always) at the expense of some of the transactional guarantees of SQL databases.

Why would you care about any of this? Document oriented databases allow for each document to store arbitrary pieces of data. This could allow for much easier customization of data storage such as when you want to store custom fields. Many of these databases also make horizontal scaling quite simple as well as providing high performance for write heavy applications.

With this in mind I figured I should look and see what’s there. So I started looking at MongoDB.

Start by creating an object to add to the database

With MongoDB, a collection is conceptually similar to a table in a SQL database. It holds a collection of related documents. A DBObject represents a document that you want to add to a collection. MongoDB automatically creates an id for each document that you add. That id is set in the DBObject after you pass it to the save method of the collection. In a real world application you might need that id to later access the document.

DBObject obj = new BasicDBObject();
obj.put("title", getTitle());
obj.put("body", getBody());
 
DBCollection coll = db.getCollection("note"));
coll.save(obj);
 
String idString = obj.get("_id").toString();

Retrieve an object previously added to a collection

To get a document from MongoDB you again use a DBObject. It does double duty in this case acting as a the parameters you want to use to identify a matching document. (There are ways you can do comparisons other than equality, of course, but I’ll leave that for a later post.) Using this as a “query by example” model we can set the _id property that we previously retrieved. The one catch is that the id is not just a string, it’s actually an instance of an ObjectId. Fortunately when we know that it’s quite easy to construct an instance with the string value.

String idString = "a456fd23ac56d";
DBCollection coll = db.getCollection(getCollectionName());
DBObject searchById = new BasicDBObject("_id", new ObjectId(idString));
DBObject found = coll.findOne(searchById);

A couple of easy examples, but it wasn’t obvious to me when I started how to get the id of a document that I just added to the database. More to come in the future.

Posted in Code, Java | Tagged , , | Leave a comment

Random but Evenly Distributed Sets of Numbers

Posted on April 17, 2010 by Geoff Lane

Let’s say one is a computer programmer and let’s say one’s wife (or roommate; or significant other) does social science research (a totally hypothetical scenario of course). When doing social science research one needs to create randomized groups of participants.

So in a group you might be testing a variable X and you need to divide the group in half to test that variable with a number of control subjects. In this scenario, one needs to create groups A and B (or 1 and 2) such that there are the same number of A and B in a given set.

Now normally when generating random numbers you can just generate and arbitrary set of random numbers. But if you need a set of 10 numbers with 5 1′s and 5 2′s then that’s a different problem. You could of course generate a set and test to make sure it’s evenly distributed and then throw it away if it doesn’t meet this constraint. That of course is an inefficient way of generating your sets because you would likely have to throw a lot of them away.

The solution to this conundrum is to use random numbers not to create your set, but to shuffle it. Luckily other smart people have proven ways to do this already. The Fisher-Yates shuffle is the technique that I used.

from random import randrange
items = [1,1,1,1,1,2,2,2,2,2]
 
# Fisher-Yates shuffle, Durstenfeld in-place implementation     
n = len(items)
while n > 1:
    k = randrange(n)  # 0..n-1
    n = n - 1
    items[k], items[n] = items[n], items[k]
 
print items    # e.g. [2, 1, 2, 1, 1, 2, 1, 2, 2, 1]

Basically the Fisher-Yates shuffle shuffle picks a random item and puts it at the end of the list by swapping the end with the randomly selected item. It then continues with the ‘unpicked’ numbers and puts them at the end of the unpicked set until it reaches the beginning of the list. Once it’s traveled through, you have a randomly sorted set.

That’s fine if you’re a programmer and want to run python from the command line and change your items set if you need a different size, etc. But if you want an end-user who’s not a programmer to use it, you better come up with something a bit configurable. So I need to allow for some variation to the sets that will be generated and shuffled.

Based on this information I created a simple class that would allow you to specify 3 properties that would define the random sets to generate: blocks, the number of individual sets; size, the number of numbers in each block; and groups, the number of variants within each block. So now you could generate a set of 10 blocks, with 12 numbers in each containing 1, 2, and 3 evenly distributed (i.e. 4 of each number).

from random import randrange
 
class Shuffler(object):
    def __init__(self, blocks, blockSize, groups):
        self.blocks = blocks
        self._groups = groups
        self._blockSize = blockSize
        self.deck = self.make_deck()
 
    @property
    def blockSize(self):
        return self._blockSize
 
    # BlockSize setter also initializes deck
    @blockSize.setter
    def blockSize(self, value):
        self._blockSize = value
        self.deck = self.make_deck()
 
    @property
    def groups(self):
        return self._groups
 
    # Groups setter also initializes deck
    @groups.setter
    def groups(self, value):
        self._groups = value
        self.deck = self.make_deck()
 
    def is_valid_group_size(self):
        return self.blockSize % self.groups == 0
 
    # Fisher-Yates shuffle, Durstenfeld in-place implementation
    def shuffle(self):            
        items = self.deck[:]    # copy deck for in-place shuffle
        n = len(items)
        while n > 1:
            k = randrange(n)  # 0..n-1
            n = n - 1
            items[k], items[n] = items[n], items[k]
        return items
 
    def make_deck(self):
        result = []
        for i in range(self.blockSize):
            result.append(i % self.groups + 1)
        return result

Finally to wrap the shuffler in a nice command-line interface I created a simple specialization of the Shuffler class that would take command line arguments to generate blocks of specific properties.

#!/usr/bin/env python
"""
Usage: %(program)s [options] ... [-b <number>] [-s <number>] [-g <number>]
Options:
  -h, --help    This help message
  -b, --blocks  The number of blocks (default: 20)
  -s, --size    The number of participants in each group (default: 10)
  -g, --groups  The number of groups in each block (default: 2)
"""
 
import random, sys, getopt
import shuffle
 
program = sys.argv[0]
 
class CliShuffler(shuffle.Shuffler):
    def __init__(self):
        shuffle.Shuffler.__init__(self, 20, 10, 2)
 
    def print_results(self):
        for i in  range(self.blocks):
            print ' '.join([str(i) for i in self.shuffle()])
 
    def usage(self):
        print >> sys.stderr, __doc__ % globals()
        sys.exit()
 
    def run(self, argv):    
        try:
            opts, args = getopt.getopt(sys.argv[1:], "hg:s:b:", ["help", "groups=", "size=", "blocks="])
        except getopt.GetoptError, err:
            # print help information and exit:
            print str(err) # will print something like "option -a not recognized"
            self.usage()
            sys.exit(2)
 
        for opt, arg in opts:
            if opt in ("-b", "--blocks"):
                try:
                    self.blocks = int(arg)
                except ValueError:
                    self.usage()
            elif opt in ("-s", "--size"):
                try:
                    self.blockSize = int(arg)
                except ValueError:
                    self.usage()
            elif opt in ("-g", "--groups"):
                try:
                    self.groups = int(arg)
                except ValueError:
                    self.usage()
            elif opt in ("-h", "--help"):
                self.usage()
            else:
                assert False, "unhandled option"
 
        if not self.is_valid_group_size():
            print("Block Size must be evenly divisible by groups to get an even grouping.")
            self.usage()
            sys.exit()
 
        self.print_results()
 
if __name__ == "__main__":
    shuffler = CliShuffler()
    shuffler.run(sys.argv[1:])

Happy shuffling…

Posted in Code, Python | Leave a comment

Announcing Grails Constraints Custom Domain Constraint Plugin

Posted on October 26, 2009 by Geoff Lane

I’ve released my first public Grails Plugin today.

The Grails Constraint plugin gives you the ability to create custom Constraints that you can apply to your Domain classes to validate them. These are applied and act just like the built in Domain class constraints.

Why would you want this?

Grails provides two generic, catch-all Constraints in the core application:

  • validator – a generic closure mechanism for validation
  • matches – a regular expression mechanism

While those work, I find myself often wanting to use the same Constraints on multiple Domain classes (think Social Security Number, Phone Number, Zipcode, etc.) and I don’t like to repeat those regular expressions or validations all over the place.

What does this plugin do?

With the Grails Constraints plugin, you can write a custom Constraint class, drop it in /grails-app/utils/ and it will automatically be available to all of your domain classes.

Example

I create a new constrain by hand in /grails-app/utils/ComparisonConstraint.groovy. (You can also use the provided create-constraint script like grails create-constraint com.foo.MyConstraint)

class ComparisonConstraint {
 
    static name = "compareTo"
    static expectsParams = true
 
    def validate = { val, target ->
        def compareVal = target."$params"
        if (null == val || null == compareVal)
            return false
 
        return val.compareTo(compareVal) == 0
    }
}

Then you can apply your constraint to your Domain class:

class Login {
    String password
    String confirm
 
    static constraints = {
        password(compareTo: 'confirm')
    }
}

See Grails Custom Constraints Plugin for the full documentation on what all of the above means and the source code.

Posted in Code, Groovy | Tagged , , | 5 Comments

DRYing Grails Criteria Queries

Posted on September 2, 2009 by Geoff Lane

When you’re writing code, Don’t Repeat Yourself. Now say that 5 times. *rimshot*

One of the things that I find myself repeating a lot of in many business apps is queries. It’s common to have a rule or filter that applies to many different cases. I came across such a situation recently and wanted to figure out a way to share that filter across many different queries. This is what I came up with for keeping those Criteria DRY.

To start with, I’ll use an example of an Article. This could be a blog post or a newspaper article. One of the rules of the system is that Articles need to be published before they are visible by end users. Because of this seemingly simple rule, every time we query for Articles, we will need to check the published flag. If you get a lot of queries, that ends up being a lot of repetition.

Here’s our example domain class:

package net.zorched.domain
class Article {
    String name
    String slug
    String category
 
    boolean published
 
    static constraints = {
        name(blank: false)
        slug(nullable: true)
    }
}

Now we need to add a query that will retrieve our domain instance by its slug (a slug is a publishing term for a short name given to an article, in the web world it has become a term often used for a search engine optimization technique that uses the title instead of an artificial ID). To perform that query we might write something like this on the Article class:

    static getBySlug(String slug) {
        withCriteria(uniqueResult:true) {
            and {
                eq('approved', true)
                eq(' slug',  slug)
            }
        }
    }

We want to query based on the slug, but we also want to only allow a published Article to be shown. This would allow us to unpublish an article if necessary. Without the approved filter, if the link had gotten out, people could still view the article.

Next we decide we want to list all of the Articles in a particular category so we write something like this, again filtering by the approved flag.

    static findAllByCategory(String category) {
        withCriteria() {
            and {
                eq('approved', true)
                eq('category',  category)
            }
        }
    }

Two simple examples like this might not be that big of a deal. But you can easily see how this would grow if you added more custom queries or if you had some more complicated filtering logic. Another common case would be if you had the same filter across many different domain objects. (What if the Article had attachments and comments all of which needed their own approval?) What you need is a way to share that logic among multiple withCriteria calls.

The trick to this is understanding how withCriteria and createCriteria work in GORM. They are both implemented using a custom class called HibernateCriteriaBuilder. That class invokes the closures that you pass to it on itself. Sounds confusing. Basically the elements in the closure of your criteria queries get executed as if the were called on an instance of HibernateCriteriaBuilder.

e.g.

withCriteria {
     eq('a', 1)
     like('b', '%foo%')
}

would be the equivalent of calling something like:

def builder = new HibernateCriteriaBuilder(...)
builder.eq('a', 1)
builder.like('b', '%foo%')

That little bit of knowledge allow you to reach into your meta programming bag of tricks and add new calls to the HibernateCriteriaBuilder. Every Class in groovy has a metaClass that is used to extend types of that Class. In this case we’ll add a Closure that will combine our criteria with other criteria like so:

HibernateCriteriaBuilder.metaClass.published = { Closure c ->
    and {
        eq('published', true)
        c()
    }
}

This ands together our eq call with all of the other parts of the passed in closure.
Now we can put the whole thing together into a domain class with a reusable filter.

package net.zorched.domain
 
import grails.orm.HibernateCriteriaBuilder
 
class Article {
 
    static {
        // monkey patch HibernateCriteriaBuilder to have a reusable 'published' filter
        HibernateCriteriaBuilder.metaClass.published = { Closure c ->
            and {
                eq('published', true)
                c()
            }
        }
    }
 
    String name
    String slug
    String category
 
    boolean published
    Date datePublished
 
    def publish() {
        published = true
        datePublished = new Date()
    }
 
    static def createSlug(n) {
        return n.replaceAll('[^A-Za-z0-9\\s]','')
                 .replaceAll('\\s','-')
                 .toLowerCase()
    }
 
    static findAllApprovedByCategory(String category) {
        withCriteria {
            published {
                eq('category', category)
            }
        }
    }
 
    static getBySlug(String slug) {
        withCriteria(uniqueResult:true) {
            published {
                eq(' slug',  slug)
            }
        }
    }
 
    static constraints = {
        name(blank: false)
        datePublished(nullable: true)
        slug(nullable: true)
    }
}

And there you have it. Do you have any other techniques that can be used to DRY criteria?

Posted in Code, Groovy, Web | Tagged , , , | 11 Comments

Struts2 Map Form to Collection of Objects

Posted on July 2, 2009 by Geoff Lane

The Struts2 documentation contains examples that are often basic at best which can make it challenging to figure out how to do things sometimes. I was working on creating a form that would allow me to select values from a list to connect 2 objects in a One-to-Many relationship. This is a common relationship for many things. In this example, I’ll use a User and Role class to demonstrate the concept.

For background, here’s a JPA mapped User and Role class.

import java.util.List;
import javax.persistence.*;
 
@Entity
public class User {
 
    private Long id;
    // ... other member variables
    private List<Role> roles;
 
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    public Long getId() {
        return id;
    }
 
    public void setId(Long id) {
        this.id = id;
    }
 
    @OneToMany
    @JoinTable(name = "UserRoles",
            joinColumns = @JoinColumn(name = "user_Id"),
            inverseJoinColumns = @JoinColumn(name = "role_Id"),
            uniqueConstraints = @UniqueConstraint(columnNames = {"user_Id", "role_Id"})
    )
    public List<Role> getRoles() {
        return roles;
    }
 
    public void setRoles(List<Role> roles) {
        this.roles = roles;
    }
 
    // ... other properties
}
 
@Entity
public class Role {
 
    private Long id;
 
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    public Long getId() {
        return id;
    }
 
    public void setId(Long id) {
        this.id = id;
    }
 
    // ... other properties
}

A list of Roles exists in the database. When a User is created, they are assigned one or more Roles. The User and Roles are connected in the Database through a join table as defined in the mapping. At this point I created some DAO Repository classes to manage the persistence and an Action to handle the form values. (The details of JPA, setting up Persistence and Actions are beyond the scope of this post.)

The part that caused me the most grief ended up being the form. I wanted to add a checkbox list that contained all of the Roles. The example on the Struts site for checkboxlist, a control with 43 documented properties is:

<s:checkboxlist name="foo" list="bar"/>

Needless to say, there was some ‘figuring out’ to be done.

The form itself is pretty vanilla for the most part. The checkboxlist is the interesting part because it’s what allows us to map the User to the Roles. I knew that I was looking for something to put into the value property of the control that would tell it to pre-select the Role values that were already associated with the User.

I started out with something like:

<s:checkboxlist name="user.roles.id"
                    list="roles"
                    listKey="id"
                    listValue="name"
                    label="%{getText('label.roles')}"
                    value="user.roles"/>

That didn’t work. When you think about it, that makes sense because the keys in the list are ids and the values supplied are Role objects. So I needed to figure out how to get the Ids from the Roles. I could have done that in the Action class, but it seemed like there should be a better way. A way that would allow me to continue in more of a Domain fashion.

Doing some research into OGNL, I came upon the list projections section which was the key…

The OGNL projection syntax gives us user.roles.{id}. Basically that is a list comprehension that takes of list of Role objects and turns it into a list of Role Ids. That list of Ids becomes the list of values that will be preselected.

Knowing that I can now create a select box that will include the pre-selected values on an edit form:

<s:checkboxlist name="user.roles.id"
                    list="roles"
                    listKey="id"
                    listValue="name"
                    label="%{getText('label.roles')}"
                    value="user.roles.{id}"/>

Enjoy.

Posted in Code, Java | Tagged , , , , | 5 Comments

Password Strength Validation with Regular Expressions

Posted on May 8, 2009 by Geoff Lane

Regular Expressions are both complex and elegant at the same time. They can be made to look like someone was just randomly hammering on their keyboard. They are also an incredibly efficient and elegant solution to describing the structure of text and matching those structures. They are very handy for defining what a string should look like and as such are very good for use in data validation.

To validate a US phone number you might create a simple regular expression \d{3}-\d{3}-\d{4} which will match a phone number like 123-555-1212. Where regular expressions can become difficult though is when the format is not quite as clear cut. What if we need to support (123) 555-1212 and just 555-1212? Well that’s where things can get more complex. But this is not about validating phone numbers. In this post I will look at how to make assertions about the complexity of a string, which is very useful if you want to enforce complexity of a user created password.

The key to making password strength validation easy using Regular Expressions is to understand Zero-width positive lookahead assertions (also know as zero-width positive lookaheads). Now that’s a mouthful isn’t it? Luckily the concept itself is a lot simpler than the name.

Zero-width positive lookahead assertions

Basically a Zero-width positive lookahead assertion is simply an assertion about a match existing or not. Rather than returning a match though, it merely returns true or false to say if that match exists. It is used as a qualification for another match.

The general form of this is:


(?= some_expression)

For example:

  • The regular expression z matches the z in the string zorched.
  • The regular expression z(?=o) also matches the z in the string zorched. It does not match the zo, but only the z.
  • The regular expression z(?=o) does NOT match the z in the string pizza because the assertion of z followed by an o is not true.

Making Assertions About Password Complexity

Now that you know how to make assertions about the contents of a string without actually matching on that string, you can start deciding what you want to actually assert. Remember that on their own these lookaheads do not match anything, but they modify what is matched.

Assert a string is 8 or more characters:
(?=.{8,})

Assert a string contains at least 1 lowercase letter (zero or more characters followed by a lowercase character):
(?=.*[a-z])

Assert a string contains at least 1 uppercase letter (zero or more characters followed by an uppercase character):
(?=.*[A-Z])

Assert a string contains at least 1 digit:
(?=.*[\d])

Assert a string contains at least 1 special character:
(?=.*[\W])

Assert a string contains at least 1 special character or a digit:
(?=.*[\d\W])

These are of course just a few common examples but there are many more that you could create as well.

Applying Assertions to Create a Complexity Validation

Knowing that these make assertions about elements in a string, but not about a match itself, you need to combine this with a matching regular expression to create you match validation.

.* matches zero or more characters.
^ matches the beginning of a string.
$ matches the end of a string.

Put together ^.*$ matches any single line (including an empty line). With what you know about Zero-width positive lookahead assertions now you can combine a “match everything” with assertions about that line to limit what is matched.

If I want to match a line with at least 1 lowercase character then I can use:
^.*(?=.*[a-z]).*$
(Which reads something like: start of string, zero or more characters, assert that somewhere in the string is a lowercase character, zero or more trailing characters, the end of the string)

The part that makes this all interesting is that you can combine any number of assertions about the string into one larger expression that will create your rules for complexity. So if you want to match a string at least 6 characters long, with at least one lower case and at least one uppercase letter you could use something like:
^.*(?=.{6,})(?=.*[a-z])(?=.*[A-Z]).*$

And if you want to throw in some extra complexity and require at least one digit or one symbol you could make a match like:
^.*(?=.{6,})(?=.*[a-z])(?=.*[A-Z])(?=.*[\d\W]).*$

There you go. Now you can create regular expressions to check the complexity of passwords.

For more help with Regular Expressions, you might want to check out:

Posted in Code | Tagged , | 8 Comments

Scala and Adding New Syntax

Posted on April 26, 2009 by Geoff Lane

One interesting thing about some languages is their support for adding new syntax. While all languages have the ability to add new functions or types some have specific properties that make it easy to add what looks like new built-in syntax.

Scala is an Object Oriented language. You can declare classes and objects, do inheritance and composition, and all the other things you might expect from an OO language. Scala is also a Functional language because functions are first-class citizens (also called a functor). And when I say Scala is an OO language I really mean it: everything is an Object. Even functions are Objects. (Chew on that one for a bit.)

Scala also supports the idea of optional parenthesis for method calls that only take a single argument (Note: This applies to method calls on object only. Not to functions.). This ends up being for a very practical reason. Take the following example:

1 + 2

This is a very nice way to write an addition operation. In reality what’s happening is:

1.+(2)

1 is an object and + is a method on that object that takes a single parameter. Applying the previous rule we get to remove the dot and the the parenthesis. Which allows us to write our previous example 1 + 2.

The good news is they bring this consistency to the language as a whole, so any method call can optionally use the dot. Any call to a method that only takes a single parameter can exclude the parenthesis around its arguments. These features make it pretty easy to emulate the built-in syntax of a language.

Your Own While Loop

Let’s say I want to write my own while loop:

def mywhile(condition: => Boolean)(command: => Unit) {
    if (condition) {
        command
        mywhile(condition)(command)
    }    
}
 
var x = 1
mywhile(x < 100000) {
    println(x)
    x += 1 
}

As you can see, I end up calling mywhile the same as I would call a built-in while. This is implemented as a tail-recursive function. If the condition is met, the command is executed. The function then recurses, calling itself to continue. x < 100000 is an anonymous function that returns a boolean expression.

Your Own Do…While Loop

A while loop can be built using just a single function. What if you want to create a do…while loop instead? In this case you can make use of the OO/functional hybrid.

class Repeater(command: => Unit){
    final def aslongas(condition: => Boolean)  {
        command
        if (condition) aslongas(condition)
    }
}
 
def mydo(command: => Unit): Repeater = {
    new Repeater(command)
}
 
var x = 0
mydo { 
    x += 1
    println(x) 
} aslongas (x < 100000)

In this case I use recursion again to do the looping. But I use an Object to bind the command to and an aslongas method to run that command and check the looping condition. I use a function mydo to bootstrap an instance of the Repeater class. Scala gives us the ability to use functions and objects when they make sense.

Why Should You Care?

Ok, so you’re not going to write your own while loops. The language has them built-in already. But what this allows you to see is how you can add new “syntax”. That ability makes it quite convenient and easy to write higher-order syntax to solve application specific problems or to create DSLs.

Update: Changed the until name to ‘aslongas’ since it really wasn’t until the condition was met.

Posted in Code, Scala | Tagged , , , | 14 Comments

Grails Embedded Classes ClassCastException

Posted on April 21, 2009 by Geoff Lane

Using ORM tools allow you to map the data to a database independently of how your object model looks. Grails supports one-to-many and one-to-one relationships if you want to have the data in different table. But what about when you want to map a single table to multiple objects? In Grails a has a relationship where all the data is stored in a single table is defined by using the embedded syntax. (This creates a component in the Hibernate mapping world.)

An example of using the embedded syntax to create a compositional relationship:

class Person {
    static embedded = ['address']
 
    String name
    int age
    Address address = new Address()
}
 
class Address {
    String street
    String street2
    String city
    String state
    String zip
 
    static constraints = {
        street2(nullable:true)
    }
}

This is all great, but…
When you attempt to databind against the Person model including Address properties, you end up with an exception:

2009-04-17 20:36:10,058 [13260127@qtp2-0] ERROR errors.GrailsExceptionResolver – java.lang.ClassCastException: Address$__clinit__closure1
org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.ClassCastException: Address$__clinit__closure1
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:92)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
at groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
at groovy.lang.Closure.call(Closure.java:279)
at groovy.lang.Closure.call(Closure.java:274)

It ends up there is a bug in Grails versions 1.0.4, 1.0.5 and 1.1 that is causing this. That bug is related to the constraints on the embedded class, in this case the Address class. Removing the constraints allows the object to be properly databound, with the obvious downside of lacking constraints.

I have filed a bug about this: GRAILS-4446. So hopefully it will be fixed soon. Hopefully if other people are having this problem they will help them out.

Update:
There is another workaround which is to declare the embedded class in its own file which makes it a first-class Domain object. When that’s done the constraints work as expected. The downside is that this means that a table will be created for the embedded domain class (and never used).

Posted in Code, Groovy | Tagged , , | 6 Comments

Update Table Data in Grails using Ajax Calls

Posted on March 27, 2009 by Geoff Lane

Using Ajax for simple forms can offer users a very clean, simple and fast way to input data. I came across a situation recently where I was looking into replacing a document based workflow with an application. The documents themselves contained a series of different kinds of transactions that could have occurred. There were not a set number of any of the types and the user needed a simple way to enter many rows of data.

Grails offers some very easy to use simple Ajax controls. The formRemote tag has an update parameter that can be used to specify a DOM element to update after the form is submitted. This is Ajax in it’s simplest form. Submit some data and replace the contents of a DOM element with a partial-page update. This works well if you want to update a div for example. But what if you want to add a row to a table? In the standard update method, you would have to re-render the entire table contents. In many cases that will be fine, but I figured I could do better than that and just render the new row and add it to the table.

Defining Domain Classes

For this example we’ll start with some simple classes. An Account can have many Checks posted against it. There are no set number, so we define a hasMany relationship between the Account and the Checks.

class Account {
    static transients = ['checksTotal']
    static hasMany = [checks:Check]
 
    Date date = new Date()
 
    Double getChecksTotal() {
        if (! checks)
            return 0
        return checks.inject(0) { current, check-> current + check.amount }
    }
 
    static mapping = {
    	  checks joinTable: false
    }
}
 
class Check {
    String name
    Double amount
    String checkNumber
    String reason
}

Creating a Controller

Next we need to create a Controller to mediate between our Domain and our Views. The Controller is setup to generate the default scaffold. We’ll end up overriding the show view to add a form on the page to easily post Checks to that Account. The action is the postCheck action. This is our Ajax action that will post the Check to the Account.

class AccountController {
 
    def scaffold = true
 
    def postCheck = {
        def account = Account.get(params.id)
        if(account) {
            def check = new Check(params)
            account.addToChecks(check)
            if(! account.hasErrors() && account.save()) {
                render template:'check', bean:check, var:'check'
            }
        }
    }
}

The postCheck method calls the render method to render a template and return it as the Ajax response. This template contains the markup for a single Check row.

You can see the check template here:

<tr>
    <td>${check?.name}</td>
    <td>${check?.checkNumber}</td>
    <td><g:formatNumber number="${check?.amount}" format="\$###,##0" /></td>
    <td>${check?.reason}</td>
</tr>

Creating the Ajax Form

Now we need to add the form to our account/show.gsp so that we can call the AccountController.postCheck action. The example form is below. The thing to notice is that we’re not using the update parameter of the formRemote, but rather the onSuccess parameter. The update method tell the Ajax callback what element to replace but we can’t do that with a table. onSuccess on the other hand allows us to handle the returned values in our own way. Here’ we’re going to call the appendTableRow Javascript function to handle the response.

In this case I definitely don’t want to replace the entire node because the first row of my table is actually the form itself. This gives it a very nice look where the data is entered under the appropriate header and then immediately shows up as the following row when the user hits enter.

<h3>Checks</h3>
<g:formRemote name="postCheck" url="[action: 'postCheck', params: [id:account?.id]]"
        onSuccess="appendTableRow('checks', e)">
    <table id="checks">
        <thead>
        <tr>
            <th>Name</th>
            <th>Check #</th>
            <th>Amount</th>
            <th>Reason</th>
        </tr>
        </thead>
        <tbody>
        <tr>
            <td><g:textField id="name" name="name"/></td>
            <td><g:textField id="checkNumber" name="checkNumber"/></td>
            <td><g:textField id="amount" name="amount"/></td>
            <td><g:textField id="reason" name="reason"/></td>
        </tr>
        <g:render template="check" collection="${account?.checks}" var="check"/>
        </tbody>
    </table>
</g:formRemote>

Luckily the appendTableRow function is made pretty easy by using the prototype APIs. The event returned to us is an HTML snippet, so in this case we just want to insert that snippet directly into the DOM which is accomplished with the insert prototype function.

function appendTableRow(tableId, e) {
    $(tableId).down('tbody').down('tr').insert({after: e.responseText});
}

In the end you have a data table that allows for easy, fast updates with almost no hassle.

Posted in Code, Groovy | Tagged , , | 5 Comments