Forum: Building VoltDB Applications

Post: Writing single-partitioned stored procedures

Writing single-partitioned stored procedures
ajgent
May 17, 2010
One aspect of VoltDB that seems to trip up a lot of new users is how single-partitioned stored procedures work. We would like to do a better job of addressing this in the documentation.

I have posted a new section we plan to add to Chapter 3 (Designing VoltDB Applications) of the Using VoltDB manual. We would be very interested in your thoughts on whether this will help people understand this important aspect of VoltDB. Please feel free to post your feedback either as replies to this post or email them to me personally at ajgent@voltdb.com.

Thank you,
Andrew
Access denied
chbussler
May 18, 2010
Hi,
when I followed the link behind 'posted' in your post, I get access denied for this: https://community.voltdb.com/system/files/writesinglepartSPs.pdf

Thanks,
Christoph
re: Access Denied
tcallaghan
May 18, 2010
Hi,
when I followed the link behind 'posted' in your post, I get access denied for this: ...
Thanks,
Christoph


Christoph,

The PDF is now available, thanks for pointing this out.

-Tim
Some feedback
chbussler
May 23, 2010
Christoph,

The PDF is now available, thanks for pointing this out.

-Tim


Hi,

thanks for dedicating a chapter to this topic. Here a few comments:

- Paragraph 3: It says "parameter that is used as the hash value for the partition". I am not sure where this chapter is placed and if at this point the definition of what a "hash value for a partition" has been given. In addition, I am not sure if mentioning "hash value" is actually necessary at this point.

- Paragraph 4: It says "other partitioned tables that are partitioned on the same hash value" in italics. At this point the definition of hash value is actually necessary. I think I remember that columns of the same type are hashed in the same way so that a value in that column from two tables result in the same has value. But this is not clear from this discussion here. At this point I would explain a lot more and possibly draw a pictorial representation of two tables that are in that situation.

- Back to Paragraph 3: It says "both the partitioning table and column and the parameter that is used as the hash value for the partition". Here it might be important to say that different columns of the same table can be used as hash value in different stored procedures to avoid the impression that it must be the same column across all stored procedures. Or must it be because of the project definition? From there it seems that it must be the same column. And what happens if there can be several project definitions for the same tables? What I try to point out here is that there are dependencies across all these that you might want to make very explicit (and possibly the fact that the partition column does not have to be the primary key).

- Bullet 3: It says "The two tables are partitioned on the same column (in this case, FLIGHTID)". I had the impression that the constraint is that the join columns are of the same data type (i.e. same hash values), not necessarily have the same column name?

- After the bullets: It says "However, the RESERVATION table cannot be joined with the CUSTOMER table in a single-partitioned stored procedure because the two tables use different partitioning columns. (CUSTOMER is partitioned on the
CUSTOMERID column.)". Now semantically it does not make sense to join with flightid = customerid at all. However, from a mechanics viewpoint, since both columns have the same data type, the join is correct in the sense from above, i.e., they have the same hash values.

- Not sure if you want to also discuss other operators in addition to "=" in this chapter, like "!=", "<", etc.

Thanks,
Christoph
re: Some Feedback
tcallaghan
May 25, 2010
Hi,

thanks for dedicating a chapter to this topic. Here a few comments:

- Paragraph 3: It says "parameter that is used as the hash value for the partition". I am not sure where this chapter is placed and if at this point the definition of what a "hash value for a partition" has been given. In addition, I am not sure if mentioning "hash value" is actually necessary at this point...

Christoph


Christoph,

Thanks for the additional feedback.

-Tim