[erlang-questions] mnesia:transform_table

Wed May 26 18:42:46 CEST 2010

Since a dict consumes more space, the advantage of the proplist is the
size. Basically, the dict will give you a performance gain that's
irrelevant (unless you have many columns) and use more space.

For example:

1> List = [{"firstname", "Igor"}, {"lastname", "Sucupira"}, {"gender",
"male"}, {"birthdate", "02/15/1981"}].
[{"firstname","Igor"},
 {"lastname","Sucupira"},
 {"gender","male"},
 {"birthdate","02/15/1981"}]
2> Dict= dict:from_list(List).
{dict,4,16,16,8,80,48,
      {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
      {{[["lastname",83,117,99,117,112,105,114,97],
         ["gender",109,97,108,101]],
        [],
        [["birthdate",48,50,47,49,53,47,49,57,56,49]],
        [],[],[],[],[],[],[],[],[],
        [["firstname",73,103,111,114]],
        [],[],[]}}}
3> GB = gb_trees:from_orddict(orddict:from_list(List)).
{4,
 {"gender","male",
  {"firstname","Igor",{"birthdate","02/15/1981",nil,nil},nil},
  {"lastname","Sucupira",nil,nil}}}

4> erlang:byte_size(term_to_binary(List)).
97
5> erlang:byte_size(term_to_binary(Dict)).
195
6> erlang:byte_size(term_to_binary(GB)).
125

8> timer:tc(lists, keysearch, ["firstname", 1, List]).
{2,{value,{"firstname","Igor"}}}
9> timer:tc(gb_trees, lookup, ["firstname", GB]).
{3,{value,"Igor"}}
10> timer:tc(dict, find, ["firstname", Dict]).
{4,{ok,"Igor"}}
11> timer:tc(lists, keysearch, ["firstname", 1, List]).
{3,{value,{"firstname","Igor"}}}
12> timer:tc(gb_trees, lookup, ["firstname", GB]).
{3,{value,"Igor"}}
13> timer:tc(dict, find, ["firstname", Dict]).
{4,{ok,"Igor"}}

On Wed, May 26, 2010 at 1:15 PM, Chris Hicks
<silent_vendetta@REDACTED> wrote:
>
> What do you see as the advantage of Proplist over a Dict though?
>
>> From: igorrs@REDACTED
>> Date: Wed, 26 May 2010 12:48:21 -0300
>> To: silent_vendetta@REDACTED
>> CC: erlang-questions@REDACTED
>> Subject: Re: [erlang-questions] mnesia:transform_table
>>
>> I thought of using a dict or a gb_trees to store the fields of each
>> entry, but I gave up in seconds (;-)), because the only advantage
>> (compared to proplists) would be the speed to retrieve a field (what
>> is very fast, anyway), once you have read the record from the database
>> (which is the slowest part).
>> Considering that the performance difference to find a field is not
>> significant if the number of fields is not big, using a gb_trees would
>> be just a waste of space, for the huge majority of the cases.
>>
>> On Wed, May 26, 2010 at 12:08 PM, Chris Hicks
>> <silent_vendetta@REDACTED> wrote:
>> >
>> > Yes I am still modeling tables and I remembered reading your blog, I'm just making sure I understand all of my options beforehand. I'm trying to decide between using a list with key-value pairs, a dict and a proplist. Are there any major disadvantages to using one of those over the other?
>> >
>> >> From: igorrs@REDACTED
>> >> Date: Wed, 26 May 2010 03:52:23 -0300
>> >> To: silent_vendetta@REDACTED
>> >> CC: erlang-questions@REDACTED
>> >> Subject: Re: [erlang-questions] mnesia:transform_table
>> >>
>> >> If you are still modelling the tables, you might also want to consider
>> >> some approach to avoid running mnesia:transform_table/3, since it
>> >> needs to rewrite all the records.
>> >>
>> >> For example, as described here:
>> >> http://igorrs.blogspot.com/2010/05/mnesia-one-year-later-part-2.html#key_value
>> >>
>> >> And discussed in this thread (from the third post on):
>> >> http://forum.trapexit.org/viewtopic.php?p=55510&sid=cc3aec96ba9387b61b5d192ccd1de1a6
>> >>
>> >> Good luck.
>> >> Igor.
>> >>
>> >> On Wed, May 26, 2010 at 2:09 AM, Chris Hicks
>> >> <silent_vendetta@REDACTED> wrote:
>> >> >
>> >> > So when updating a record definition the updated record, when reloaded, is not compatible with the old version of the record, as far as I understand it. Updating a Mnesia table to handle the new definition is straightforward enough but, my question revolves around the rest of the running system. Mainly I want to know what is the general (if there is one) process to updating a running system in this manner?
>> >> > Should you create a function which locks the whole table, reloads the code and updated all the definitions at the same time? What happens to the rest of the running system when you update a record definition while a process is in the middle of working with that old record?
>> >> > _________________________________________________________________
>> >> > The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail.
>> >> > http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5
>> >>
>> >>
>> >>
>> >> --
>> >> "The secret of joy in work is contained in one word - excellence. To
>> >> know how to do something well is to enjoy it." - Pearl S. Buck.
>> >>
>> >> ________________________________________________________________
>> >> erlang-questions (at) erlang.org mailing list.
>> >> See http://www.erlang.org/faq.html
>> >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>> >>
>> >
>> > _________________________________________________________________
>> > Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
>> > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1
>>
>>
>>
>> --
>> "The secret of joy in work is contained in one word - excellence. To
>> know how to do something well is to enjoy it." - Pearl S. Buck.
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
> _________________________________________________________________
> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

-- 
"The secret of joy in work is contained in one word - excellence. To
know how to do something well is to enjoy it." - Pearl S. Buck.