NULLability in data storage is different than NULLability in program. In the relational database world, NULL is used to signify an unknown - the value could be anything. If you have a record that only has a key (Primary Key for those playing along in SQL-land), and no value, then you can't do much with it so Riak wouldn't want to track it. You probably wouldn't want to store it in the RDBMS either.
If you do want to store Riak's equivalent of NULL, you could store an empty JSON object (or appropriately mucked object for your serialization mechanism). The record would still be present in Riak, but it wouldn't show up for many queries. The bigger question, though, is "Why do I want to store a completely empty record?" Looking at your question, you may want to devise a "This is not a value" value. This is frequently done in data warehousing and other delightful places so that there is confusion about what a value means. Example: you're tracking the sales of goods in a store. Eventually you decide you want to see how goods are performing based on shelf location. When you add that data into your database, you can store a NULL, but that means you don't know where the goods were at the time. Instead you add a lookup for "Location not tracked" and then store the location for the SKU after you go live with the feature. To be fair, I could go either way with the situation you mentioned. I'd probably store no data unless there is customization and just provide sane defaults in the app code to cope with an absence of data. TL;DR - magic numbers suck and NULLability is a holy war. --- Jeremiah Peschka Founder, Brent Ozar PLF, LLC On Thursday, June 23, 2011 at 9:00 AM, Keith Bennett wrote: > Speaking of deleting keys, I have a question. It may be naive, as I'm a > developer, but not very specialized in data storage issues, especially > key/value stores. > > I don't think I've brought this up on this list, but if I have, I apologize, > and feel free to ignore this message. (I couldn't find it in the message > store, but know I've spoken with some folks about it.) > > If specifying a null value for a given key removes that key from riak, then > there is no way to differentiate between an explicit specification of null, > and the absence of a value specification. The two can represent two different > cases. > > For example, the code might assume a default value, unless overridden, and > null might be one of the values that could be used to override it. An example > might be that the value represents the name of a class to instantiate to > perform a given operation, and a null value would signify that no operation > was wanted. > > Would this be some kind of violation of some important data storage > principle? Or do others not see this as a useful distinction? > > Thanks, > Keith > > > > > On Jun 23, 2011, at 10:57 AM, Andrew Thompson wrote: > > > On Thu, Jun 23, 2011 at 09:59:38AM +0200, Runar Jordahl wrote: > > > As this discussion shows, deleting objects in an eventual consistency > > > database is complicated. The concept of multiple APIs to do a delete, > > > and the possibility of having objects reappear, can scare new > > > customers away from Riak. > > > > > > I understand delete is complicated, but Basho should make it as simple > > > as possible to understand. They should provide a single, simple, > > > well-documented delete API, and document how delete happens. > > > > > > I find it unnatural to use the PUT operation to do a delete. I > > > understand the API compatibility issues, but for new users this can be > > > quite confusing: ?So you are telling me there are two APIs I can use > > > to delete an object? Why!?? In my mind, changing the DELETE API would > > > be far better. After all, Riak is still not legacy software. > > > > > > A wiki page describing how delete is done in a Riak system should be > > > created. The wiki page should describe how delete happens internally: > > > Which API to use (PUT or DELETE), tombstone concepts, etc. It should > > > describe current bugs, and future plans. In addition the page should > > > describe how the client app should handle deletes: Can you configure > > > tombstone lifetime? Pros/cons of using own tombstones, when can > > > deleted objects reappear, and how to detect and handle that. > > > > I agree that we should do a writeup on deletes, past present and future. > > I'll try to put something together in the next few weeks. > > > > Andrew > > > > _______________________________________________ > > riak-users mailing list > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
