4D mantiene coerenti le selezioni di record per quanto riguarda la cancellazione dei record.

Tradotto automaticamente da Deepl

La cancellazione dei dati deve essere gestita con cura. Per evitare problemi, si possono utilizzare le transazioni o affidarsi a backup e registri.

In 4D 20 R4 sono stati apportati alcuni miglioramenti per rendere le selezioni di record stabili e coerenti per quanto riguarda la potenziale cancellazione di record in questa selezione.

Continuate a leggere per scoprire come il vostro codice 4D sarà sempre più sicuro.

Comportamento interno del 4D

Come forse già sapete, 4D gestisce internamente una tabella di indirizzi per puntare ai blocchi fisici di dati sul disco. Per quanto riguarda la gestione di questa tabella di indirizzi nell’architettura interna di 4D, ciò potrebbe portare ai problemi discussi qui quando si procede a una selezione di record.

Quando un record viene cancellato, il suo riferimento ai dati fisici viene cancellato nella tabella degli indirizzi.

Per evitare buchi e ottimizzare l’uso della memoria per la tabella degli indirizzi, quando viene creato un nuovo record, 4D utilizza gli spazi liberi in questa tabella degli indirizzi.

Una volta costruita una selezione di record (ad esempio con una query), se un record appartenente a questa selezione viene cancellato e viene creato un nuovo record, questo può essere referenziato attraverso lo stesso numero di record precedente nella tabella degli indirizzi.

In questo modo, in passato, potreste trovare nella vostra selezione alcuni dati che non vi aspettate affatto.

un esempio concreto

Un dipendente ha una pila di compiti da gestire. Quando viene creata, l’attività ha lo stato TO DO.

Periodicamente, viene inviata una mail al dipendente con i suoi compiti da svolgere. Viene creata una selezione di questi compiti e su ciascuno di essi viene eseguito un ciclo per fornire i dettagli nell’e-mail.

Ma l’amministratore ha il permesso di eliminare alcuni compiti. Se l’amministratore elimina per errore un’attività nella selezione di cui sopra e subito dopo viene creata una nuova attività per un altro dipendente… cosa succede?

Prima di 4D 20 R4

L’attività appena creata è stata trovata nel ciclo e, poiché si tratta di un’attività per un altro dipendente, è completamente fuori dal campo di applicazione!

Dopo 4D 20 R4

L’attività appena creata non viene trovata nel ciclo e la selezione dei dati è sempre coerente e si può fare affidamento su di essa in modo sicuro.

Il caso d’uso sopra descritto non è così frequente, perché la maggior parte delle volte si cambia lo stato di un record invece di cancellarlo direttamente.

O forse siete abituati a verificare nuovamente la coerenza di un record/entità (rispetto ai criteri di selezione) prima di procedere.

In ogni caso, non dovrete più preoccuparvi di questo.

vediamo questo in azione in un po’ di codice

Nell’esempio che segue costruiamo la selezione delle entità di $target.

Dopodiché, cancelliamo un’entità appartenente a questa selezione di entità (lo facciamo nello stesso pezzo di codice per una rapida comprensione, ma possiamo immaginare che questo venga fatto da un altro utente in un altro processo).

Il ciclo elabora solo le due entità rimaste (ID interno 10 e 12).


var $target; $customers : cs.CustomersSelection
var $customer : cs.CustomersEntity
var $newCustomer : cs.CustomersEntity
var $status : Object

// Three customers are retrieved with internal ID 10, 11, 12
$target:=ds.Customers.query("internalID >= 10 and internalID <= 12")
ASSERT($target.length=3)

// We delete the customer with internalID = 11
$customers:=ds.Customers.query("internalID = :1"; 11).drop()

// We create a new customer with internalID = 99 
$newCustomer:=ds.Customers.new()
$newCustomer.internalID:=99
$status:=$newCustomer.save()

// We loop on the $target entity selection
// got before the creation of the new customer
For each ($customer; $target)
// The new customer is not in the entity selection ... 
ASSERT($customer.internalID#99)
End for each 

Importante: questa funzione si applica ai dati gestiti con i classici comandi QUERY standard di 4D e con ORDA.

Continuate a lavorare con 4D in tutta sicurezza: la vostra piattaforma di sviluppo preferita si fa carico di molti problemi per permettervi di concentrarvi sulla logica aziendale!

Avatar
- Product Owner - Marie-Sophie Landrieu-Yvert è entrata a far parte del team 4D Product come Product Owner nel 2017. In qualità di Product Owner, è incaricata di scrivere le storie degli utenti e di tradurle in specifiche funzionali. Il suo ruolo è anche quello di assicurarsi che l'implementazione della funzionalità fornita soddisfi le esigenze del cliente.Marie-Sophie si è laureata presso la scuola di ingegneria ESIGELEC e ha iniziato la sua carriera come ingegnere presso IBM nel 1995. Ha partecipato a vari progetti (di manutenzione o di costruzione) e ha lavorato come sviluppatrice Cobol. In seguito ha lavorato come progettista UML e sviluppatore Java. Ultimamente i suoi ruoli principali erano l'analisi e la scrittura dei requisiti funzionali, il coordinamento dei team di business e di sviluppo.