Hello Joem,
thank for your post.


By default, SEBLOD offer 3 Storage Types:

• Standard: 1 field = 1column in database. It's the storage you have to use in 99% of cases.
• JSon: because Joomla store some data with this storage
• Custom: x fields = 1 column in database. Use this storage only for FieldX and GroupX

I say again, in 99% of cases, use this storage:


When you create a fieldX, you have to use the storage "CUSTOM", because a fieldX allow you to repeat X time, a field in a form, and each values are stored in the same column in the database.
The name for the storage must be :

When you create a GroupX, you also have to use the storage "CUSTOM", because a groupX allow you to repeat X times, a content type in a form, and each value of each fields of the repeated content type are stored in the dame column in database:
In the content type which will be repeated, for all fields, put the storage "NONE". They will be store in the groupX field.

IMPORTANT FOR CUSTOM STORAGE
it's not because you use the custom storage that you have to store your data in the #__content "introtext" field.
SEBLOD use the storage custom for introtext only to store an ID to make the bridge between Joomla and SEBLOD and for NOTHING else, So, storing each field in his own column is better and it's the good way.

Now, where you must store your fields.
In general, in a content type, fields are specially use for this content type, so don't unlock the padlock, and SEBLOD will create a new table prefixed with "#__cck_core_store_for" and add the name of you content type, so the table will be named :


Now, if you want that some fields stay available for all content type, you just have to unlock the padlock, or simply create your fields from the SEBLOD Fields Manager. They will be store in the table
depending on the object you are working on.

You say:
My final and most important concern is possible data migration in case Seblod is no longer the solution. What work flows are there to convert Seblod data into normal Joomla articles if required?

If you only use existing field and never create new fields, you won't need to do something to remove SEBLOD.
At the first time you will create new content Type, new fields, you won't be able to get back, because Joomla can't do what SEBLOD do, and if you use SEBLOD it's because Joomla alone is poor.


Best regards.
Lionel

Thanks Lionel, this is a very clean and informative post. I think you should copy this to Manuals page.

+1
I agree, those infos are very crucial! I really would like to see this in a comprehensive docs article. Also appreciated are examples, usecases and pros/cons. For instance: Why is one option preferred etc., Are there any drawbacks...
Thanks in advance!

++1
Glad to have found this post.
Must be documented.
Keep it up!

Hello Lionel,

I'm just stumbling across this post now. It is great how you explain storage options in a very clear way and easy to understand.

Like others here, I think this should definitly go into the manuals as is. Would make live easier for anyone who's new to Seblod.

Cheers
Gerhard

Hi!

Have you seen the Tutorial on storage?

regards,

Randy

This is all very helpful and clears up a lot of high level problem.  There is some spotty information on the internet about this which easily confuses newer users like myself. What's still not clear are the ramifications of choosing the wrong storage type (although I think I am about to learn the hard way)?  Seblod almost works too well in some ways.  If you are building just one Content Type with a handful fields the system is very forgiving and everything works. The implications start becoming more clear when you have multiple content types which share common fields such as date selectors in groupx and want to build a search list across across all that data (based on date in this example).  If I understand the above correctly you could make it unsearchable if you choose the wrong storage type.  Is that correct or Seblod even more forgiving than I think?  

Hi Bucklash,

the custome storage is really

CUSTOM | Article | column_name[fieldname]

which mean

• column_name => the name that will take the column in the database
• field_name => the name of the field

Why?

Because the custom storage allow you to store more than 1 field in 1 column, something like:

• Field 1 => CUSTOM | Article | my_column[field1]
• Field 2 => CUSTOM | Article | my_column[field2]
• Field 3 => CUSTOM | Article | my_column[field3]
• ....

All 3 fields will be store in the column "my_column"

Regards.

Lionel