Can you assign a default value to a custom profile field for everyone?

[rcane]

I have a field I'd like to add, but for starts I'd prefer to just set it to a zero (0) and keep it visible only to me.  I want to do some coding with, but I'm not sure how to get around it not "being there" until someone fills it out--which they can't do.

Is there a way to take a custom field (in this case 'cust_unused') and give everyone a value of 0 for it?

[Arantor]

The only way is to just bulk insert it into the database.

[rcane]

The only way is to just bulk insert it into the database.

Can you give an example?  I'm not sure of it given the table uses id-theme along with the other 3.   Just don't want to disturb the fragile ecosystem that is the themes table

[Arantor]

id_theme for custom fields should be 1 in all cases so it's loaded regardless of theme that you're on.

[rcane]

id_theme for custom fields should be 1 in all cases so it's loaded regardless of theme that you're on.

Ok, so 1 for the id_theme, but I'm not sure I understand the query structure--especially since themes has 3 primaries and a unique.

Any inserts are going to recognize the existing id_members, no?
And, updates will change existing records?

How do you insert into a table, when you have to make the row have a primary/unique key that's already in the table doing other things?

[Arantor]

I'm not sure what the problem is here. It's not 3 primaries, it's 1 primary made of three parts - a user id, a theme id and a field id, has one value.

It's a rule to ensure that you don't end up with 'user 1, theme 1, field my_field' having two values, because it's a primary key made up of all three items.

It's really very straight forward: you insert one row per user per value you're inserting, as in id_member is 1, id_theme 1, variable cust_unused, value 0. Then again for id_member 2, and id_member 3 and id_member 4 and so on.

Each specific user/custom field has a unique combination, that's what the primary is setting up... I thought you understood all this already since you've been working with it so much already...

[rcane]

I'm not sure what the problem is here. It's not 3 primaries, it's 1 primary made of three parts - a user id, a theme id and a field id, has one value.

It's a rule to ensure that you don't end up with 'user 1, theme 1, field my_field' having two values, because it's a primary key made up of all three items.

It's really very straight forward: you insert one row per user per value you're inserting, as in id_member is 1, id_theme 1, variable cust_unused, value 0. Then again for id_member 2, and id_member 3 and id_member 4 and so on.

Each specific user/custom field has a unique combination, that's what the primary is setting up... I thought you understood all this already since you've been working with it so much already...

The things I've been working with haven't had to address something like this--not that it's complicated, only that it's just different.  A first time to see something that way.  I hadn't really seen a structure on a table I was about to interact with have multiple keys (i know what you said, i'm just lost for a better description).   I called it that because looking in PMA the structure shows primaries and id-member has unique (which makes sense of course).

Dragging things out of the themes table took some schooling to get the queries proper. 
I should have expected that putting things back in would as well.

I'll take another look at it tomorrow.  I do appreciate the description.   

I need to go get some literature on the different 'ways' you can structure tables when it's not just 40 columns with one key.