Ticket #942 (closed Defect: fixed)

Opened 6 years ago

Last modified 5 years ago

Deleting a child type programmatically should not depend on an activated Type Editor plugin

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.8
Component: DeepaMehta Standard Distribution Version: 4.7
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 5 Area: Application Framework / API
Module: deepamehta-core

Description

When a plugin migration deletes a child type at a time when the Type Editor plugin is not yet activated, the parent type's sequence will break, resulting in a corrupted DB. The workaround for the plugin developer is to let the plugin wait for the activation of the Type Editor plugin (using the importModels plugin property). This should not be required as it causes serious DB problems if forgotten.

See #900 for more background.
Thank you, Malte, for revealing this problem!

Change History

comment:1 Changed 6 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 6 years ago by Jörg Richter <jri@…>

In f8077ec9154ceada6978b56ae5731a0581ab09d2/deepamehta:

Move Type Editor logic to Core (#942, #935).

Deleting a child type in a migration no longer depends on an activated Type Editor plugin.

The server-side Type Editor logic is now integrated into Core.
The Type Editor plugin now contains solely client-side rendering logic.

BREAKING CHANGES

1 call dropped from Core Service:

TypeStorage getTypeStorage()

The TypeStorage has not a public interface anymore.

See #942.
See #935.

comment:3 Changed 5 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.