ASP.NET 2.0 Membership

[Ray Booysen]

Hi all

I am using the membership provider and am storing all the login details
via this system.

However, I require to add additional fields that may change over time
that are related to the User. E.g. DOB, Place of birth and all that.

What is the best way to do this? Create a second table taking the
primary key of the aspnet_Users table and use this as a foreign key in
my new table?

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

Regards
Ray

 

[Riki]

Try using profiles. They are a built in extension for the membership
provider.

 

[Ray Booysen]

Thanks, I'll take a look!

Regards
Ray

Try using profiles. They are a built in extension for the membership
provider.

 

[clintonG]

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCountyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

 

[Erik Funkenbusch]

However, I require to add additional fields that may change over time
that are related to the User. E.g. DOB, Place of birth and all that.

No, that's not what membership is about. Membership is not a full user
store, it's merely a way to verify authentic users.

What is the best way to do this? Create a second table taking the
primary key of the aspnet_Users table and use this as a foreign key in
my new table?

Yes, that's a good solution.

Can I extend the provider to take these new fields? If so, how do I
change it in case of new fields?

No, Like I said, Membership is not a general data store. You should write
your own routines to access this data seperately. Trying to tie it into
the membership provider is always a recipe for headaches.

 

[Ray Booysen]

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCountyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

Do the profiles API not expose methods to retrieve all profiles for all
users?

 

[clintonG]

That's a documentation question ainna?

 

[Ray Booysen]

Let's say you store the properties of each Member as a Profile and want to
query the data for all members from Milwaukee for example or all males over
the age of 35 or whatever. The entire profile for each member is stored as a
series of characters concatenated to one another and stuffed into a single
column. The algorythm for parsing a series of characters concatenated to one
another without a delineator is done how? The answer is we have to write a
sh!tload of code after figuring out how to interpret an undocumented schema
that is present in the Profile table itself.

//A Profile Entry Example:
ClintonGallagherWauwatosaWisconsin53226MilwaukeeCountyMale5241477415624147741562http://clintongallagher.metromilwaukee.com

See what I mean?
AFIC Profiles are FUBAR and only marginally useful as a replacement for the
Session object for issues related to the state of the application, i.e data
that is not queried intending to be returned as a group of related records.

Somebody correct me if this is wrong...

ProfileInfoCollection profiles = ProfileManager.GetAllProfiles();

I don't see how your problem occurs now?

With this collection we can write simple code to retrieve the
information we require.

Am I missing something?

Regards
Ray

 

[Erik Funkenbusch]

ProfileInfoCollection profiles = ProfileManager.GetAllProfiles();

I don't see how your problem occurs now?

With this collection we can write simple code to retrieve the
information we require.

One problem is one of scale. Suppose you have 1 million users. You now
have to retrieve all 1 million profiles, then write code to iterate over
them rather than using a simple SQL query to only return the profiles you
are interested in.

Apart from the huge amount of memory this will use, it will also allocate a
lot of small objects, then have to destroy them in GC, all of which suck up
system resources.

 

[Brock Allen]

AFIC Profiles are FUBAR and only marginally useful as a replacement

for the
Session object for issues related to the state of the application, i.e
data
that is not queried intending to be returned as a group of related
records.
Somebody correct me if this is wrong...

Profile is meant to be long term storage of user data, which is different
than the intent of session. The odd persistence choice you're commenting
on is an aspect of the SqlProfileProvider. You can choose a different provider
which can store your data differently. I'd suggest googling for the "Table
Profile Provider" which is a sample provider from MSFT that will store each
profile property in a distinct column in your database.

-Brock
http://staff.develop.com/balle

 

[clintonG]

Damn Brock your one very useful dude Thanls for the heads up.