Erlang Mailing Lists

Author Message

<  Erlang questions mailing list  ~  ets:next/2 behavior - set vs. ordered_set

Guest
Posted: Mon Sep 12, 2011 3:46 pm Reply with quote
Guest
I'm currently developing a disk based clone of the ets application. During testing with QuickCheck and Proper, I stumbled upon a difference between set and ordered_set for the real ets:next/2 operation.

The last command exits with badarg rather than '$end_of_table' as I would expect.

Can someone comment on this behavior? Is this a bug? Is this a documentation bug?

thanks,



18> ets:new(ordered_set,[ordered_set,public,named_table,{keypos,2}]).
ordered_set
19> ets:first(ordered_set).
'$end_of_table'
20> ets:next(ordered_set,0).
'$end_of_table'
21>

21> ets:new(set,[set,public,named_table,{keypos,2}]).
set
22> ets:first(set).
'$end_of_table'
23> ets:next(set,0).
** exception error: bad argument
in function ets:next/2
called as ets:next(set,0)
24>




$ erl -v
Erlang R14B03 (erts-5.8.4) [source] [64-bit] [rq:1] [async-threads:0] [kernel-poll:false]

Eshell V5.8.4 (abort with ^G)



next(Tab, Key1) -> Key2 | '$end_of_table'

Types Tab = tid() | atom()
Key1 = Key2 = term()

Returns the next key Key2 , following the key Key1 in the table Tab . If the table is of
the ordered_set type, the next key in Erlang term order is returned. If the table is of
any other type, the next key according to the table's internal order is returned. If
there is no next key, '$end_of_table' is returned.



Joseph Wayne Norton
norton@alum.mit.edu



_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Mon Sep 12, 2011 9:17 pm Reply with quote
Guest
# Joseph Wayne Norton 2011-09-12:
> I'm currently developing a disk based clone of the ets application.

Interesting, I was considering doing something like that for an upcoming
project -- are you planning to make the result open source by any chance?

Wink

> During testing with QuickCheck and Proper, I stumbled upon a difference between
> set and ordered_set for the real ets:next/2 operation.
>
> The last command exits with badarg rather than '$end_of_table' as I would expect.
>
> Can someone comment on this behavior? Is this a bug? Is this a documentation bug?

FWIW I've always read this:

next(Tab, Key1) -> Key2 | '$end_of_table'

Returns the next key Key2, following the key Key1 in the table Tab.

as "behaviour is undefined if Key1 isn't a key in Tab". That ordered_set
tables support even non-key items has been mentioned on the mailing list
in passing some while ago, I've found it very surprising...

BR,
-- Jachym
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Mon Sep 12, 2011 11:33 pm Reply with quote
Guest
Yes, that is my plan after the basic features and tests are in place.

On 2011/09/13, at 6:17, Jachym Holecek <freza@circlewave.net> wrote:

> # Joseph Wayne Norton 2011-09-12:
>> I'm currently developing a disk based clone of the ets application.
>
> Interesting, I was considering doing something like that for an upcoming
> project -- are you planning to make the result open source by any chance?
>
> Wink
>
>> During testing with QuickCheck and Proper, I stumbled upon a difference between
>> set and ordered_set for the real ets:next/2 operation.
>>
>> The last command exits with badarg rather than '$end_of_table' as I would expect.
>>
>> Can someone comment on this behavior? Is this a bug? Is this a documentation bug?
>
> FWIW I've always read this:
>
> next(Tab, Key1) -> Key2 | '$end_of_table'
>
> Returns the next key Key2, following the key Key1 in the table Tab.
>
> as "behaviour is undefined if Key1 isn't a key in Tab". That ordered_set
> tables support even non-key items has been mentioned on the mailing list
> in passing some while ago, I've found it very surprising...
>
> BR,
> -- Jachym
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Tue Sep 13, 2011 12:55 am Reply with quote
Guest
On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
<norton@lovely.email.ne.jp> wrote:
>
> I'm currently developing a disk based clone of the ets application.

Can you elaborate how this is different from dets, or are you doing it
for learning?
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Tue Sep 13, 2011 2:07 am Reply with quote
Guest
The basic goal is to build and test a production worthy replacement for ets with disk based storage. After I have the basics in place, I can elaborate further.

thanks,

Joseph Norton

On Sep 13, 2011, at 9:55 AM, OvermindDL1 wrote:

> On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
> <norton@lovely.email.ne.jp> wrote:
>>
>> I'm currently developing a disk based clone of the ets application.
>
> Can you elaborate how this is different from dets, or are you doing it
> for learning?

_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Tue Sep 13, 2011 9:42 am Reply with quote
Guest
Joseph Wayne Norton wrote:
> I'm currently developing a disk based clone of the ets application. During testing with QuickCheck and Proper, I stumbled upon a difference between set and ordered_set for the real ets:next/2 operation.
>
> The last command exits with badarg rather than '$end_of_table' as I would expect.
>
> Can someone comment on this behavior? Is this a bug? Is this a documentation bug
It is the intended behavior.
I don't think the documentation is contradicting but it could be much
more clearer and contain something like:

For tables of the ordered_set type, next/2 will succeed regardless of
Key1. For other tables Key1 must exist in the table or have existed the
last time the tables was "unfixed" (see safe_fixtable/2), otherwise
badarg is thrown.


/Sverker, Erlang/OTP

_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Fri Sep 16, 2011 6:46 pm Reply with quote
Guest
In what way is dets not production worthy?

Sincerely,


jw

--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Mon, Sep 12, 2011 at 7:07 PM, Joseph Norton <norton@lovely.email.ne.jp (norton@lovely.email.ne.jp)> wrote:
Quote:

The basic goal is to build and test a production worthy replacement for ets with disk based storage.   After I have the basics in place, I can elaborate further.

thanks,

Joseph Norton


On Sep 13, 2011, at 9:55 AM, OvermindDL1 wrote:

> On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
> <norton@lovely.email.ne.jp (norton@lovely.email.ne.jp)> wrote:
>>
>> I'm currently developing a disk based clone of the ets application.
>
> Can you elaborate how this is different from dets, or are you doing it
> for learning?

_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org (erlang-questions@erlang.org)
http://erlang.org/mailman/listinfo/erlang-questions






Post received from mailinglist
Guest
Posted: Fri Sep 16, 2011 7:47 pm Reply with quote
Guest
The main issues that I'm aware of are that a dets file can't be larger
than 2GB, ordered_set isn't supported, repair is often not very fast,
and the only way to defragment a table is to close it and re-open it
with repair set to force (mostly a problem because of the 2GB limit).

http://www.erlang.org/doc/man/dets.html

On Fri, Sep 16, 2011 at 11:46 AM, Jon Watte <jwatte@gmail.com> wrote:
> In what way is dets not production worthy?
> Sincerely,
> jw
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
> On Mon, Sep 12, 2011 at 7:07 PM, Joseph Norton <norton@lovely.email.ne.jp>
> wrote:
>>
>> The basic goal is to build and test a production worthy replacement for
>> ets with disk based storage.   After I have the basics in place, I can
>> elaborate further.
>>
>> thanks,
>>
>> Joseph Norton
>>
>> On Sep 13, 2011, at 9:55 AM, OvermindDL1 wrote:
>>
>> > On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
>> > <norton@lovely.email.ne.jp> wrote:
>> >>
>> >> I'm currently developing a disk based clone of the ets application.
>> >
>> > Can you elaborate how this is different from dets, or are you doing it
>> > for learning?
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

Post received from mailinglist
Guest
Posted: Fri Sep 16, 2011 10:24 pm Reply with quote
Guest
That is my understanding too.

jwnorton@i.softbank.jp

On 2011/09/17, at 4:47, Bob Ippolito <bob@redivi.com> wrote:

> The main issues that I'm aware of are that a dets file can't be larger
> than 2GB, ordered_set isn't supported, repair is often not very fast,
> and the only way to defragment a table is to close it and re-open it
> with repair set to force (mostly a problem because of the 2GB limit).
>
> http://www.erlang.org/doc/man/dets.html
>
> On Fri, Sep 16, 2011 at 11:46 AM, Jon Watte <jwatte@gmail.com> wrote:
>> In what way is dets not production worthy?
>> Sincerely,
>> jw
>>
>> --
>> Americans might object: there is no way we would sacrifice our living
>> standards for the benefit of people in the rest of the world. Nevertheless,
>> whether we get there willingly or not, we shall soon have lower consumption
>> rates, because our present rates are unsustainable.
>>
>>
>>
>> On Mon, Sep 12, 2011 at 7:07 PM, Joseph Norton <norton@lovely.email.ne.jp>
>> wrote:
>>>
>>> The basic goal is to build and test a production worthy replacement for
>>> ets with disk based storage. After I have the basics in place, I can
>>> elaborate further.
>>>
>>> thanks,
>>>
>>> Joseph Norton
>>>
>>> On Sep 13, 2011, at 9:55 AM, OvermindDL1 wrote:
>>>
>>>> On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
>>>> <norton@lovely.email.ne.jp> wrote:
>>>>>
>>>>> I'm currently developing a disk based clone of the ets application.
>>>>
>>>> Can you elaborate how this is different from dets, or are you doing it
>>>> for learning?
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@erlang.org
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist
Guest
Posted: Sat Sep 17, 2011 4:48 am Reply with quote
Guest
So, by transitivity, the same reasons mnesia is annoying for large data sets?

Sincerely,


jw

--
Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable.



On Fri, Sep 16, 2011 at 12:47 PM, Bob Ippolito <bob@redivi.com (bob@redivi.com)> wrote:
Quote:
The main issues that I'm aware of are that a dets file can't be larger
than 2GB, ordered_set isn't supported, repair is often not very fast,
and the only way to defragment a table is to close it and re-open it
with repair set to force (mostly a problem because of the 2GB limit).

http://www.erlang.org/doc/man/dets.html


On Fri, Sep 16, 2011 at 11:46 AM, Jon Watte <jwatte@gmail.com (jwatte@gmail.com)> wrote:
> In what way is dets not production worthy?
> Sincerely,
> jw
>
> --
> Americans might object: there is no way we would sacrifice our living
> standards for the benefit of people in the rest of the world. Nevertheless,
> whether we get there willingly or not, we shall soon have lower consumption
> rates, because our present rates are unsustainable.
>
>
>
> On Mon, Sep 12, 2011 at 7:07 PM, Joseph Norton <norton@lovely.email.ne.jp (norton@lovely.email.ne.jp)>
> wrote:
>>
>> The basic goal is to build and test a production worthy replacement for
>> ets with disk based storage.   After I have the basics in place, I can
>> elaborate further.
>>
>> thanks,
>>
>> Joseph Norton
>>
>> On Sep 13, 2011, at 9:55 AM, OvermindDL1 wrote:
>>
>> > On Mon, Sep 12, 2011 at 9:46 AM, Joseph Wayne Norton
>> > <norton@lovely.email.ne.jp (norton@lovely.email.ne.jp)> wrote:
>> >>
>> >> I'm currently developing a disk based clone of the ets application.
>> >
>> > Can you elaborate how this is different from dets, or are you doing it
>> > for learning?
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org (erlang-questions@erlang.org)
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org (erlang-questions@erlang.org)
> http://erlang.org/mailman/listinfo/erlang-questions
>
>






Post received from mailinglist

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum