Hi Peter, On Mon, Oct 21, 2019 at 12:32 AM Peter Bozek via 4D_Tech < [email protected]> wrote:
> I am plying with ORDA and LB displaying related records and run into one > problem: When I delete related record with drop(), entity selection > accessed through link does not change (probably because documentation says > that entity stays in memory and is just deleted from disk.) > I would need to reinitialise linked records by something like RELATED MANY > commands, but do not see such command in ORDA. > and On Mon, Oct 21, 2019 at 2:55 AM Peter Bozek via 4D_Tech < [email protected]> wrote: > On Mon, Oct 21, 2019 at 9:39 AM Christian Sakowski < > [email protected]> wrote: > > > Normally, just call entity.reload() to refresh an entity and its > related selections. > That would work, but wanted to avoid that as I would loose changes done to > the edited record, or loose the record when it is new. A couple of thoughts. It sounds like you have a situation where you have something like an old-school input form: form is displaying a single record with a listbox showing some child records. When the user deletes a child record you want the listbox to refresh to show the updated selection. And the reason you don't want to use entity.reload() is because this would compel saving changes to the parent/new record. Have I got that right? My first thought is why would you allow the user to delete a child record and NOT save the parent? Just wondering what makes that a problem. (And - yes I did just ask the equivalent of "why would you want to do that?") Next, you could wrap the editing process in a transaction. I haven't tried to see if .reload() respects the state of the transaction but I expect it to. This isn't my preferred way of handling this sort of thing but it's an option. Another thought is to manage the selection of child records manually. It's trivial to set up and would accommodate the situation of saving/deleting child records independently of what happens on the parent. There's no rule that says you _have_ to use the relation in the entity and no penalty for not using it. You could move the related selection to a collection for editing/display too. Yet another thought is to abstract the editing to the equivalent of a variable and edit the variable. You can use the .toObject() method to change the contents of a record to an object. This gives you total flexibility without the overhead of a transaction. Your edit form could have Form.displayRecord which is this object. For a new record you can use entity.FromObject(Form.displayRecord). If you use UUIDs for the primary key you can assign it to the object and then use it as the actual PK. To update an existing object you will need to loop through the properties. It's an extra step but gives you very fine control over what gets saved when. Just some thoughts. ORDA makes it incredibly easy to put data on the screen in any number of ways. -- Kirk Brooks San Francisco, CA ======================= What can be said, can be said clearly, and what you can’t say, you should shut up about *Wittgenstein and the Computer * ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
