Update docs: how2 use collection with same functionality as repeater

[surips]

I have a repeater in my contenttype in Bolt v3 like so:

        features:
            type: repeater
            fields:
                title:
                    type: text
                image:
                    type: image
                    extensions: [ gif, jpg, png ]
                teaser:
                    type: text
                    class: large
                content:
                    type: html   

Thereby in my contenttype I can add a new feature which includes a title, an image, a teaser and content.
Now, I would like to have the same in v4, but I saw that repeaters do not longer exist. I tried to achieve the same functionality by changing the type from repeater to collection. But then, I can only add the different fields one by one and that is not what I want. I would like to have the exact same functionality of a repeater of v3 in v4. Do I need to use a set? I did not find an example how to do this in the docs.

Thank you in advance

[panda-madness]

I haven't played around with Bolt 4 yet, but skimming through the docs I imagine you're supposed to make a collection of set fields, something along the lines of:

        features:
            type: collection
            fields:
                content:
                    type: set
                    fields:
                        title:
                            type: text
                        image:
                            type: image
                            extensions: [ gif, jpg, png ]
                        teaser:
                            type: text
                            class: large
                        content:
                            type: html   

You can add more than 1 set field to mimick the old named repeater functionality, or just add 1 for a regular repeater.

[bobdenotter]

@panda-madness Nailed it! 👍

Basically, to replicate the old 'repeater' behaviour, you can wrap the fields in a type: set. Does that make sense? (asking so i can make sure the docs are clear, when I write them)

[surips]

I tried @panda-madness suggestion and inserted it into my contenttypes.yaml. On first glance it seemed to have worked, as I could input my content like I wanted. But when I clicked on the save button a ForeignKeyConstrainViolationException occured: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails.

I still can save my progress on other contenttypes, but not on this one. Do you have any idea why this exception occured and how I can fix it?

[bobdenotter]

@surips More information, please.. Read this: https://bolt.tips/entry/reporting-issues-effectively

[surips]

Yes, sorry. Again:
So I inserted this into my contenttype in my contenttypes.yaml:

        slides:
            type: collection
            fields:
                content:
                    type: set
                    fields:
                        firsttext:
                             type: text
                        firstimage:
                             type: image
                        secondtext:
                             type: text
                        secondimage:
                             type: image

As I mentioned before, this seemed to work, because I was able to use it and input content, as if it was a repeater, just like I wanted. But when I wanted to save the new content the exception occured (after clicking on the save button). I will enclose a screenshot of the exception. Do you need any more information? As mentioned I am on v4.0.0

[bobdenotter]

@surips Thanks.. Additional question: What's the output of bin/console bolt:info ?

[surips]

@bobdenotter This:

[wgaulke]

Update regarding the issue: We dropped and recreated the database after Update to RC3.

The issue still remains. However, the first entry can be made. Only, when editing the collection and saving it again the error occurs.
I know, we should not be guessing, but it looks like the collection elements are dropped and reinserted on save and the ordering of queries seems to be off so that the FK_constraint kicks in.

[bobdenotter]

@surips @wgaulke

I've been trying to confirm this report, but so far i haven't succeeeded. My contenttype:

dummies:
    name: Dummies
    singular_name: Dummy
    fields:
        title:
            type: text
        slug:
            type: slug
            uses: title
        veld:
            type: textarea
        slides:
            type: collection
            fields:
                content:
                    type: set
                    fields:
                        firsttext:
                            type: text
                        firstimage:
                            type: image
                        secondtext:
                            type: text
                        secondimage:
                            type: image
    icon_many: "fa:viruses"
    icon_one: "fa:virus"

And my bolt:info

 Bolt version: 4.0.0 RC 15

 * Install type: Git clone
 * Database: mysql 5.7.26 - 127.0.0.1 via TCP/IP (with JSON)
 * PHP version: 7.2.21
 * Operating System: Darwin - 18.7.0

I can add, save, delete, save again.. Seems to work as expected. I do think my colleague fixed an ussie with foreign keys a while ago, so it just might've been fixed in the mean time.. I'll leave this open for now until either you confirm it's working now, or until I can reproduce it as an error. :-)

[JTNMW]

I've been experiencing the same issue with collections and sets on mysql, encountering foriegn key update/delete constraints when updating a record with a collection containing field sets.

I resolved the issue by changing the Index affected from restrict to cascade via phpmyadmin.
from:
.

to:

is there a preferred/recommended fix other than this?

[surips]

@bobdenotter For the first release we have chosen to leave this functionality out, due to the exception. But we will probably integrate it soon for future releases, so I'll keep you updated :-)

[bobdenotter]

@surips Sure thing, we'll leave this one open, and if new information comes to light, we'll fix it if needed. :-)

[bobdenotter]

@JTNMW,

I resolved the issue by changing the Index affected from restrict to cascade via
phpmyadmin. from:

The annotations around the definition of that field does allow us to tweak its behaviour:

https://github.com/bolt/core/blob/master/src/Entity/Field.php#L73-L76

    /**
     * @ORM\ManyToOne(targetEntity="Bolt\Entity\Field", cascade={"persist"})
     */
    private $parent;

Maybe one of the different options for persist would work better?

[JTNMW]

After a fresh project setup with 4.0.0.rc17 and MYSQL, and with the following collection + set added to the pages contenttype.yaml

fields:
  publications:
            type: collection
            collapsible: true
            label: Publications
            group: Selected Publications
            fields:
               publication:
                  type: set
                  label: Publication
                  fields:
                    publication:
                      type: html
                    resource:
                      type: file

I am able to add, edit and delete sets in the collection and save the parent record.

However, foreign key constraint still happens if i try to delete the parent record if it contains child records in the collection/sets fields.

I tried changing the 'cascade={"persist"}' (adding "remove") without success. Foriegn key problem is still occuring.

I have found that adding this to the field.yaml L#73 before the running bolt:setup sets the "on Delete" to CASCADE for the relation and the foreign key issue is resolved.

 /**
     * @ORM\ManyToOne(targetEntity="Bolt\Entity\Field", cascade={"persist"})
     * @ORM\JoinColumn(onDelete="CASCADE")
     */
    private $parent;

Having "on delete" set to CASCADE brings the foreign key relationship in line with the "Taxonomy" and "Relations" tables of the DB.

I havent ome across any conflicts having the database schema set like this.

Please try include the Collections/set (ie repeater from bolt 3) in the stable version. It is much needed feature.

[bobdenotter]

Having "on delete" set to CASCADE brings the foreign key relationship in line with the "Taxonomy" and "Relations" tables of the DB.

That makes sense. Would you like to make a small PR to effect that change? That way you'll get "credits" for the fix.

Please try include the Collections/set (ie repeater from bolt 3) in the stable version. It is much needed feature.

The new collections are intended as a superset of the old repeaters/blocks from V3. I'm aware I need to write docs for it though.

Is there anything in specific you're trying to do with it, that you can't manage in v4? I'll happily provide some help to get it working! :-)

[surips]

@bobdenotter Just wanted to let you know, that I have tried out the Collection / Set combo to replace a Repeater and it works! :)

[bobdenotter]

@surips Good to hear! Thanks for the feedback.

[I-Valchev]

This was fixed in documentation: bolt/docs#1052