Обсуждение: Bitfields always atomic? Other way to store attributes?

Dear List;

If I have two threads modifying the same "bit" field:   thread1=> update table set bf=bf | '01000'   thread2=> update
tableset bf=bf | '10000'
 
Will this operation always be safe (e.g. result in bf='11000')?  Or must
I wrap things in
explicit transactions?

My application is to give attributes to an address table.  But maybe
there is a better way?

I want to mark each addresses with attributes, e.g. the person may be a
"friend", "on my holiday card list", "owe me money", be an "employee", a
"volunteer on the xxx project", or none of the above.

I could assign each role a bit.

Or, create a string field: "Friend,Money, Emp,VolXXX".

Or, create related tables:       friend_pk,         address_id       cardlist_pk,       address_id       money_pk,
 address_id,    amount_owed       volunteer_pk,    address_id
 

Any thoughts?
                       -Bryce Nesbitt
     

-- 
----
Visit http://www.obviously.com/

Bryce Nesbitt wrote:
> If I have two threads modifying the same "bit" field:
>     thread1=> update table set bf=bf | '01000'
>     thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')?  Or
> must I wrap things in
> explicit transactions?

Each of these commands will be its own transaction if you don't 
explicitly start one.

> My application is to give attributes to an address table.  But maybe
> there is a better way?

Create 5 boolean fields.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Am Sonntag, 26. März 2006 23:47 schrieb Bryce Nesbitt:
> Dear List;
>
> If I have two threads modifying the same "bit" field:
>     thread1=> update table set bf=bf | '01000'
>     thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')?

yes, Thats what "ACID" (http://en.wikipedia.org/wiki/ACID) is all about.

> Or must
> I wrap things in
> explicit transactions?

every statement is in it's own transaction as long as you dont start one by
yourself.

> My application is to give attributes to an address table.  But maybe
> there is a better way?
>
> I want to mark each addresses with attributes, e.g. the person may be a
> "friend", "on my holiday card list", "owe me money", be an "employee", a
> "volunteer on the xxx project", or none of the above.
>
> I could assign each role a bit.
>
> Or, create a string field: "Friend,Money, Emp,VolXXX".
>
> Or, create related tables:
>         friend_pk,         address_id
>         cardlist_pk,       address_id
>         money_pk,        address_id,    amount_owed
>         volunteer_pk,    address_id
>
> Any thoughts?

create a table with attributes and a table with addresse "address" and then
link them via a third table address_addressattributes, something like this:

create table address ( add_id serial not null primary key, add_name text not null, add_street ... ...
);

create table addressattributes ( aa_id serial not null primary key, aa_name text not null unique
);

insert into address_attributes (aa_name) values ('Friend');
insert into address_attributes (aa_name) values ('Money');

create table address_addressattributes ( add_aa_id serial primary key, aa_id int4 not null references
address_attributes(aa_id), add_id int4 not null references address (add_id) 
)

this is called a many-to-many relation.


kind regards,
janning

> If I have two threads modifying the same "bit" field:
>     thread1=> update table set bf=bf | '01000'
>     thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')?  Or

Won't this always result in bf='11xxx', depending on the
original values of bf?

TJ
www.gnova.com

TJ O'Donnell wrote:

> > If I have two threads modifying the same "bit" field:
> >     thread1=> update table set bf=bf | '01000'
> >     thread2=> update table set bf=bf | '10000'
> > Will this operation always be safe (e.g. result in bf='11000')?  Or
>
> Won't this always result in bf='11xxx', depending on the
> original values of bf?

Not even.  Consider:

thread1=> update table set bf=bf | '01000'
thread3=> update table set bf=bf & '10111'
thread2=> update table set bf=bf | '10000'

Now you get bf=10xxx.

They're thread safe in that all transformations will be applied as-if serially, so no bit sets or unsets will be lost,
butyou can't guarantee that another client won't interfere with the results.