| Author |
Message |
|
| Guest |
Posted: Mon Sep 12, 2011 3:46 pm |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Mon Sep 12, 2011 9:17 pm |
|
|
|
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?
> 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 |
|
|
| Back to top |
|
| Guest |
Posted: Mon Sep 12, 2011 11:33 pm |
|
|
|
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?
>
>
>
>> 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 |
|
|
| Back to top |
|
| Guest |
Posted: Tue Sep 13, 2011 12:55 am |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Tue Sep 13, 2011 2:07 am |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Tue Sep 13, 2011 9:42 am |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Fri Sep 16, 2011 6:46 pm |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Fri Sep 16, 2011 7:47 pm |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Fri Sep 16, 2011 10:24 pm |
|
|
|
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 |
|
|
| Back to top |
|
| Guest |
Posted: Sat Sep 17, 2011 4:48 am |
|
|
|
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 |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
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
|
|
|