+2 votes

I'm missing the option to select fields from the base entity when defining an index on the derived entity. For performance reasons we need to define an index that is composed of fields from both the base and the derived entity.

in Solved by (400 points)
recategorized by

Thanks for posting. As we discussed on the chat, we will try to find a way how to implement it.

Hello. What is the situation with the development of this feature?

Unfortunately this feature requires a lot of changes in the app core. Currently each entity is handled independently and because of that it's not easy to choose fields from different entity.

We have it in our todo list but I can't promise any term right now.

Thank you, the problem is clear.
Please tell me, how to make so that the indices that have been added manually, not overwritten?

Unfortunately currently isn't an easy way how to do that. Skipper always updates all ORM definitions to current project state so any manual change will be overwritten.

Also it's not possible to exclude one file from whole export because of problem with model consistency.

Can you add custom index definition property?

How such custom index property should work? Is it only a workaround to this feature or is it some Doctrine feature?

Same as column-definition property of field. It is only a workaround.

2 Answers

+1 vote
Best answer

This feature is now implemented in latest beta.

Feel free to check it here: https://support.skipper18.com/402/downloads-skipper-beta

by Skipper developer (141k points)

Thanks for fixing1!

You're welcome. If you find some time please test it and let me know if everything works as expected. Thanks!

0 votes

I am adding my support to this request for having the ability to include inherited fields to indexes. I can currently do it manually by manually adding a line to the Entity class, e.g.

@ORM\Table(indexes={@ORM\Index(name="index_name", columns={"field_a","field_b"})})

But the line that defines the index gets overwritten the next time I export from Skipper, so this is not a nice solution.

by (160 points)

You're right. This is currently the only way. We have a plans to add support for this feature in the future. The same behavior will be required by traits which we want to support too.

Currently we're working on namespace support and after that we want to take a look at inheritance+traits.

What is the status of this feature? I am stumbling upon this now as well, since we want to derive a class from the Gedmo Loggable AbstractLogEntry class but also set indexes.

Hi Joern, it's on top of our todo list but it's not ready yet. Unfortunately it's not as easy what it might look.