46 Posts
joem
10 years ago
12
Topic
Seblod is great. I am just a little confused about Storage. I am rolling out a large site and don't want to make a mistake.

I understand what each Storage option does however I am not very clear when to use which type of storage.

A lot of tutorials have you dumping data into the Introtext field. That feels messy to me right now and is begging for heartache down the road. In some examples an addition field value is added to introtext (ex: introtext[newfield]). It's never explained why I would do this versus the default of introtext. Are these valid concerns?

I would think that storing data in their own columns at the end of the content table or separate content type database table is the cleanest. Likewise I would think that making every field unlocked and available throughout the system would be the most extensible choice. Is there something wrong with all the fields being shared?

Not sure why but I understand that Groupx and Fieldx need to be created as Custom. Should these fields be stored in content type database column too?

Do the fields inside a content type that will be used as a group (or groupx) need to be created differently for any reason?

Not sure where the traps are. It appears that there are any number of ways to paint yourself into a corner and/or possibly screw up your site when you have 1,000's of pages.

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?

Any help would be very appreciated.

Get a Book for SEBLOD
10 years ago
5
Level 1
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:
STANDARD | Article | column_name


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 :
CUSTOM | Article | column_name[fieldname]


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:
CUSTOM | Article | column_name[fieldname]

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 :
#__cck_core_store_form_contentTypeName


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
#__cck_core_store_item_content or #__cck_store_item_users
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
52 Posts
melihtas
10 years ago
0
Level 2
Thanks Lionel, this is a very clean and informative post. I think you should copy this to Manuals page.
233 Posts
pepperstreet
10 years ago
0
Level 2
+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!
26 Posts
isometriq
9 years ago
0
Level 2
++1
Glad to have found this post.
Must be documented.
Keep it up!
449 Posts
gebeer
9 years ago
1
Level 2
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
693 Posts
rpoy
9 years ago
0
Level 3
Hi!

Have you seen the Tutorial on storage?

regards,

Randy
46 Posts
joem
9 years ago
0
Level 1
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?  
1283 Posts
Bucklash
8 years ago
0
Level 1

Hi folks

Just clarifying this statement:

CUSTOM | Article | column_name[fieldname]

Actually means:

CUSTOM | Article | [the name of my field which will be created as a column name]

ie

If I create a field called 'funky_socks' it will look like this:

CUSTOM | Article | funky_socks
8 years ago
3
Level 1

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

1283 Posts
Bucklash
8 years ago
0
Level 2

Hi Lionel

that is an 'aaaah - I see' moment. 

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"

Thanks for that

Jon

12 Posts
Hozefa Saleh
7 years ago
1
Level 2

Hi Lionel,

If I create a field-x named "biz_gallary_group" , the storage should be Custom >> Article >> gallery_column[biz_gallary_group]  ?

Please suggest me is this a good naming convention?

Thanks

Hozefa

7 years ago
0
Level 3

Hi Hozefa saleh,

sorry for the delay, we were working on the Joomla Day France last weekend...

The format is the good one. After that, for the naming you can use what you want, like for exemples :

  • gallery[image]
  • items[item]
  • galleries[item]
  • ....


Regards.

Lionel

Get a Book for SEBLOD