create hash with no fields

[Aaron Boxer]

Hello,

I am using a hash to store the results of an sql query; the data is
layed out as follows

sql_query_key => {result1_key => result1, result2_key => result2,......}

What if the result set is empty? I still want to store the fact
that there are no results. So, is there a way of creating a hash with no fields?

Otherwise, I suppose I can store a magic value that indicates no results.

Thanks,
Aaron

[Demis Bellot]

Hey Aaron,

By Hash do you mean Dictionary<string,string>? in which case you can just store 'null' as the value no?

Redis like most schema-less data stores treats a non-existent collection the same as an empty collection.

If an operation targeting an aggregate data type (list,set,zset,hash) is performed against a non existing key, the behavior should be exactly the one obtained running the operation against an empty aggregate value of the same type. So for instance LLEN returns 0 if called against a non existing key, because we consider it holding an empty list.

http://antirez.com/post/redis-weekly-update-4.html

You can still use EXISTS (http://redis.io/commands/exists) on any type of key to determine if it exists or not.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Aaron Boxer]

Thanks, Demis. A redis hash with no fields, in my use case, indicates
that the query returned no results.
If the key doesn't exist, then this indicates that the query has not
been cached. So, I would like to differentiate
between these two situations. I suppose I could store the number of
results in a special (field, value) pair.

[Salvatore Sanfilippo]

Hello Aaron,

you can't make an empty Hash, so you have two possibilities:

1) if you are sure a given field name can't exist in an actual hash,
just make sure to set it to a different value in the two cases. So if
the query returned a null value, you set hash to just: is_null => 1.
Otherwise you set it to is_null => 0 and all the other fields are set
accordingly to your goals.

2) Solution "1" does not work if your other fileds can be everything,
so they can collide. You can still use a prefix. But you may also
select to just set the key to a simple string "NULL". Type will be
able to tell the difference, but I linke more solution 1 as it will
involve less commands both to test the hash, and to set it to a
different value if later the query will return a non null value.

Ciao,
Salvatore

--
Salvatore 'antirez' Sanfilippo
http://invece.org

"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele

[Aaron Boxer]

#1 should work for me.

Thanks!
Aaron

[Andy Lawman]

One solution would be to use a second key to hold the SQL queries that returned a null result, at the cost of more complex code. A set seems a good choice with O(1) performance for SADD, SREM and SISMEMBER.

Andy.

IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the addressee/s above.  It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws.  If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system.

Amadeus Services Ltd, World Business Centre 3, 1208 Newall Road, Hounslow, Middlesex, TW6 2TA, Registered number 4040059

[Salvatore Sanfilippo]

On Thu, Jan 6, 2011 at 12:02 PM, Andy Lawman <ALa...@amadeus.com> wrote:
> One solution would be to use a second key to hold the SQL queries that
> returned a null result, at the cost of more complex code. A set seems a good
> choice with O(1) performance for SADD, SREM and SISMEMBER.

All this schemas, including "2" that I suggested, have the problem
that you need to perform two queries for reading the data. And two
queries for update.

With the additional hash field approach you just do HGETALL anyway
when reading. And HSET when writing.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

[Aaron Boxer]

Thanks, guys. Having such a supportive community for Redis is truly awesome.

I think I will opt for adding an extra hash field, indicating empty/not empty.

--Aaron