Fortunately for the programming world, I'm currently mainly in the business of
consuming APIs rather than designing them :p
> On 30 May 2019, at 14:01, Michael Gentry <blackn...@gmail.com> wrote:
>
> I'm a fan of well-named things ... deleteWithoutMercy and
> horribleMutantRuntimeWithoutRelationships are fabulous!
>
>
> On Thu, May 30, 2019 at 6:44 AM Hugi Thordarson <h...@karlmenn.is> wrote:
>
>> Hi Jurgen,
>>
>> thanks for the suggestions :). I made a horrible hack just now, based on
>> the idea of having a different model, but instead of modifying files, I
>> remove the relationships in memory. This actually works but it would be
>> interesting to hear the point of view of others—am I potentially shooting
>> myself in the foot by firing up a copy of my ServerRuntime within the same
>> JVM, based on the same (but modified in memory) model? Any potential
>> conflicts?
>>
>> public void deleteWithoutMercy( final List<DataObject> objectsToDelete ) {
>> final ServerRuntime horribleMutantRuntimeWithoutRelationships =
>> NBCore.createServerRuntime( Props.defaultProps() );
>>
>> horribleMutantRuntimeWithoutRelationships
>> .getDataDomain()
>> .getEntityResolver()
>> .getObjEntities()
>> .forEach( objEntity -> {
>> new ArrayList<>(
>> objEntity.getRelationships() ).forEach( relationship -> {
>> objEntity.removeRelationship(
>> relationship.getName() );
>> } );
>> } );
>>
>> final ObjectContext localOC =
>> horribleMutantRuntimeWithoutRelationships.newContext();
>> final List<DataObject> localObjects = new ArrayList<>();
>>
>> for( final DataObject objectFromAnotherRuntime : objectsToDelete )
>> {
>> localObjects.add( localOC.localObject(
>> objectFromAnotherRuntime ) );
>> }
>>
>> localOC.deleteObjects( localObjects );
>> localOC.commitChanges();
>> }
>>
>>
>> *shudder*
>>
>> - hugi
>>
>>
>>> On 30 May 2019, at 07:13, Jurgen <do...@xsinet.co.za> wrote:
>>>
>>> Hi Hugi
>>>
>>> So crazy idea number one is to maybe duplicate your model and revise the
>> delete rules, then use this DeleteModel to nuke the customer. The downside
>> of this is having to maintain two models, maybe not such a good idea ?
>>>
>>> Idea number two is to add a delete method to each of the classes that
>> first deletes the children. So you have:
>>>
>>> Customer ->> Invoice ->> InvoiceLine ->> InvoiceLineSums
>>>
>>> Then add deleteLineSums() to InvoiceLine that deletes its
>> InvoiceLineSums with something like: getObjectContext().deleteObjects(
>> getLineSums() );
>>>
>>> Do the same in Invoice where deleteLines() is something like:
>>>
>>> for ( InvoiceLine line : getLines() ) line.deleteLineSums();
>>> getObjectContext().commitChanges();
>>> getObjectContext().invalidateObjects( this );
>>> getObjectContext().deleteObjects( getLines() );
>>>
>>> Then the same for Customer .... The downside of all this is that it's
>> not very efficient in terms of DB calls, but then you won't have to go all
>> caveman like and "write out damn joins like our ancestors did" :-)
>>>
>>> Cheers
>>> Jurgen
>>>
>>
>>
