MyBB Community Forums

Hello.
Image an "ETC" field in some tables e.g members, posts, forums, anouncements, favorites, threads,.......
that makes adding a "field" easier to that record.
Yes just one field for adding many fields.
times and times in source code objects of a forum 4example a thread or a user , or a forum , fetched from DB as an "ARRAY" if we fetch them as before but fetch "ETC" field as a "seriaized string" we can insert an array that have many fields in it and we have no need to change db structure for just a little change.
Image you are a plug-in writer that want to add a "Description" for all of threads. if you want to do standard you have to 1-change dbstructure for adding a "desc" field 2-use a low priority existing field e.g. "notes" in threads table, 3-unserialize existing "ETC" and add a "desc" => "notes description" to it and re serialize it and update record.
IS NOT 3nd metod easier? ofcourse.
I can provide more infos for this trick "from what we need to do and where we should and what is changes in next version tooo analizing compatiblity and even how can implement it in admin area and normal scripts?"
as i know we have not many time to arriving 1.2, so i offer that if 1.2 have db struct changing, it include a etc field with larg capacity in it and we will implement this feature next vers.
Whats Your Idea?

I'm not quite sure I understand you, here is what I think you said.

You have a field where plugin creators can insert their own data for each post/thread/user on the relevant table (mybb_users, mybb_posts etc)?

If so, I think it's a bad idea. How would a plugin search for the required data? Say you need to order users on a new column, you wouldn't be able to do that this way. Also, when you try to uninstall the plugin, removing that data would take ages depending on the size of the forum. Each user would have to be read, the 'etc' column would have to be deserialized, remove the data, and then reserialise and update.

Hello decswxaqz 8-} ( i kill my self for your name)
thanks for your corporating.
are you agree with main idea? having a field rather than some for each plugin ? ( i hope you know flews of that methods... they are realy cheap and if this method will implemente good that was realy an invent :-"

Let me improve implement method. what is your idea about:
addslashing values before serializing, this way we can be sure that between two double quotations , there are realy our data if have not \"
and a regulare expression that fortunately MySQL supports that can solve search and mass update problem.
it is just an idea and i dont work on it for implementing detailes. may have some probs but worth for test. any better idea?

dear decswxaqz .
did you read my post? could i answer you? havent any idea? or are you still think that i dont worth?
regs

What if there are more than 1 plugins using the same field in a table?

Tikitiki Wrote:What if there are more than 1 plugins using the same field in a table?

answer is :
what if a plugin wants to create a table or a field for its data or delete a setting group? it will result to a confilict. so plugin writers should prevent. by selecting a uniq names and also testing that if it exists?
there are many ways to save & register a new fields. e.g. have a default setting (not deletable) in settings table. or many others.
whats your idea?

Plugins can create a new column on the table - I think that's more efficient for some plugins that need to rapidly sort or search for data.

What will happen with the data integration?
if adding a field was good , what is the philsophy of user fields table? how many plugins can add how many fields into tables and who can garantee that next versions can support them?
I am seeking a method, that plugins can insert theire data without any these risks or at least lower risk.
and need your help to implement it.

well I have about 30 userfields at the moment and don't see any problems....and since you can define these fields also be 'not updateable by the user (=hidden to them)i don't see any reason why plugins couldn't use this table to store data

Hello Kimmo.
but my answer is not in your post. many bad systems can work for many years.
i wonder that have any one agree with me in approach of "one field rather than many one"? My God...