incubator-deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [PATCH] Introduces blob metadata - Adds ability to specify arbitrary user metadata (KEY-VALUE) for S3, Cloudfiles and Azure, during blob creation
Date Tue, 01 Feb 2011 17:16:33 GMT
still playing with .inject :) ...

(for the azure driver) the azure server responds with a metadata hash like:

{:x_ms_blob_type=>"BlockBlob", :date=>"Tue, 01 Feb 2011 17:07:07 GMT", 
:content_type=>"text/plain", :x_ms_lease_status=>"unlocked", 
:x_ms_version=>"2009-09-19", :x_ms_meta_v=>"2.1", 
:etag=>"0x8CD8CFB422A88C4", :x_ms_meta_foo=>"bar", 
:content_length=>"86", :server=>"Windows-Azure-Blob/1.0 
Microsoft-HTTPAPI/2.0", :last_modified=>"Fri, 28 Jan 2011 12:08:50 GMT", 

The above hash is 'waz_blob.metadata'. I needed to extract a new hash 
which I call 'blob_metadata', containing all the key:value where key was 
'x_ms_meta_' (blob metadata key). So, especially for Michal:

waz_blob.metadata.inject({}) { |result_hash, (k,v)| blob_metadata[k]=v 
if k.to_s.match(/x_ms_meta/i)}

:) thanks


On 01/02/11 17:08, Michal Fojtik wrote:
> On 31/01/11 22:52 +0200, wrote:
>>> Yes, actually it's ;-) There is an article
>>> about functional programming, which describes this.
>> This site is a ruby book (pdf) - by article i assume you meant
>> chapter... i tried searching but only thing I could find was a
>> comparison of using .inject vs using recursion. However its a pretty
>> big book so I may well have missed the relevant bit.
> Maybe it's not this book, but meta-programming one but I saw some
> comparison between looping vs inject in some of them. I'll do the job today
> and do detailed research in those book.
>> That got me curious; what *actually* is the advantage of using
>> .inject. Don't get me wrong, I still think its pretty cool and elegant
>> in its concise expressiveness, but most search results seem to suggest
>> that .inject is actually slower (for this case, it makes no
>> difference, since the input will never really be a HUGE structure; we
>> are talking about key:value pairs for blob metadata). The way I
>> understood it, if you are handling large data structures, the
>> resultant object is returned at each 'loop' of the inner code block,
>> making it expensive.
> Did some research and I found:
> So yes, it seems like I was wrong and it's slow. But if I understand it
> correctly
> it's just implementation issue, so in meantime (eg in Ruby 1.9) it should
> be fast.
> The reason why I like .inject() is that it's one of the Ruby fundamental
> features and it's more 'ruby-ish' ;-) So besides that current
> implementation is slow, it can be improved by programmers and it's
> always good to use it now than refactor later (from my point of view).
> But you're right that in this particular case (blob) it absolutely doesn't
> matter what approach we choose.
>>> Anyway, it's not a blocker, just small hint (I found myself .inject very
>>> useful when I was doing some meta programming in client library. It
>>> saves
>>> variables and lines of code (and it's better for garbage collecting)).
>> In this particular case it doesn't save variables ( I assume you're
>> referring to the instantiation of the resulting structure, 'user_meta'
>> in this case). Do you have a reference/article/explanation for the
>> 'better for garbage collecting' (aka, please give me a reason to use
>> .inject rather than .each, since the former is clearly much cooler),
> I did some research about that and I found this 'hint':
> When is each useful? Simple: when you want to create side-effects, like
> saving to the database, printing a result, or sending a web service call.
> In these cases, you’re not concerned with the return value; you want to
> change state on the screen, the disk, the database, or something else.
> But don’t use each if you want to extract some new value from an array.
> That’s not what it’s for. Instead, take a look at three other powerful
> functions: map, inject, or select.
> -- Michal
>> marios

View raw message