volunteer wanted to write a few FAQ entries about Mnesia

Laszlo Varga <>
Mon Feb 24 14:27:44 CET 2003


Hello,
from my little practice, I have the feeling that the explicit concept
depends on the task, what the aggregate keys are intended to used for.
You might need them for reordering, for augmentation, for table extension,
for modelling hiearchial data structures, or whatelse.
Through my eyes, SNMP is not a concept, but a bunch of allowed concepts,
so difficult to generalize.

Laszlo Varga





> From: Chandrashekhar Mullaparthi <>
> To: "'Chris Pressey'" <>, Ulf Wiger 
<>
> Cc: , 
> Subject: RE: volunteer wanted to write a few FAQ entries about Mnesia
> Date: Mon, 24 Feb 2003 12:58:13 -0000
> MIME-Version: 1.0
> 
> mnesia:match_object 
> mnesia:select 
> 
> achieve this, but you are right, there is no explicit concept of aggregate
> keys.
> 
> Chandru
> 
> -----Original Message-----
> From: Chris Pressey [mailto:]
> Sent: 21 February 2003 22:05
> To: Ulf Wiger
> Cc: ; 
> Subject: Re: volunteer wanted to write a few FAQ entries about Mnesia
> 
> 
> On Fri, 21 Feb 2003 11:53:02 +0100 (MET)
> Ulf Wiger <> wrote:
> 
> > On Thu, 20 Feb 2003, Chris Pressey wrote:
> > 
> > >Records are accessed by a single key (which may be unique
> > >or duplicate) and there is no concept of a secondary key.
> > 
> > Actually there is. You can define an index on a non-key
> > attribute, and access records using mnesia:index_read/3 or
> > index_match_object/2.
> 
> Oops!  I meant there is no concept of an aggregate key, i.e. of using
> multiple fields to identify a record.
> 
> -Chris
> 
> 
> 
>  NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential.  If you have received
> this email in error please notify the sender immediately and delete this
> email from your system without copying or disseminating it or placing any
> reliance upon its contents.  We cannot accept liability for any breaches of
> confidence arising through use of email.  Any opinions expressed in this
> email (including attachments) are those of the author and do not necessarily
> reflect our opinions.  We will not accept responsibility for any commitments
> made by our employees outside the scope of our business.  We do not warrant
> the accuracy or completeness of such information.
> 




More information about the erlang-questions mailing list