02 July 2009

Print E-Z



This project had a very unique requirement: They wanted to dynamically serve up their products without augmenting their application with a server-side technology like PHP or Java. More specifically, they wanted their products to be pulled from a datasource instead of being statically specified in HTML.

Hmm...

What if we used a data source that could be hosted elsewhere and served over Javascript?

GoogleBase to the rescue!

In this project, we used GoogleBase to store their products and then javascript to read them from GoogleBase and render them on the correct pages.

It was tricky, but we were successful.

Relationships

There was just one problem that we found during implementation, and that was that Google Base just wasn't prepared to have many integer values assigned to a single attribute. We needed this in order to map each product to the pages that it ought to appear on.

To make a long story short, we tried countless strategies over the course of a couple of weeks until the following thought dawned on me:

What if we assigned a prime number to each value and created composite numbers for each product's unique set of values, which we could then extract back out using modular arithmetic?

I'm sure that the thought occurred to you right away. Of course, it took me a couple of weeks to see it.

So here is what I did in the end:

Each page number would be assigned a unique prime number. So "Page 1" would be assigned the number "2", "Page 2" would be assigned "3", "Page 3" would be assigned "5", etc. The set of pages that an individual product should appear on can then be expressed as a set of those prime numbers:

Product A's 'page_numbers'-> {17, 3, 93, 41}

"But wait," you say. "Google Base won't let us specify a list of integers as a value in the data feed!" You speak well. What we will do now is multiple those prime numbers together to get a composite number, which will become the value for the "page_numbers" attribute.

17*3*93*41 = 194463

Product A's 'page_numbers' -> 194463

Now, if you stretch back to high school math, you'll remember that ever composite number is a product of primes (remember what they called "prime factorization"). This concept ensures that there is only one prime factorization per integer and thus, will not be divisible by any other primes than those that make up its prime factorization.

This is important because now I can say with confidence that if product xyz's 'page_numbers' attribute is divisible by 43, then it must belong on the page that is assigned to the prime number '43'.

Modular arithmetic is perfect for such a calculation. The question "Does x mod y equal 0?" is the same as asking "Does y divide evenly into x?"

So, the math works. Now, will Google Base support it?

It turns out that their Ranking Language does support modular arithmetic and can act as a secondary filtering mechanism after its Query Language. Yes!

Upon reading the documentation, I use the following Ranking Language code:

orderby=[x = page_number(int) : if ( x % 43 == 0 ) then x else fail()]

Drum roll.....

............

...It fails. Expected an 'int' for the '%' operator, but found 'page_number(int)'.

What? **Heart sinks**

Well, I won't tell you about the resulting melancholy that weighed on my stricken heart for the next 48 hours while I stewed over what had gone wrong.

Instead, I'll just tell you that I found out that since each attribute is able to have multiple values (just not necessarily through a data feed), I needed to apply an aggregating function on the value before applying the mod.

So, then I tried:

orderby=[x = page_number(int) : if ( max(x) % 43 ) then max(x) else fail()]

And it worked!

It's always fun running into problems like that because there is an interesting solution hanging right around the corner.