- Salesforce Composite Batch API per describe SObject: le describe sono ora
raggruppate in chunk da 25 e inviate come singole POST a /composite/batch,
riducendo le chiamate API da N a ceil(N/25); per 200 SObject: da 201 a 9 chiamate.
- Discovery entita' REST in parallelo: DiscoverEntitySummariesAsync e
DiscoverEntitiesAsync avviate simultaneamente; la lista entita' diventa
interattiva subito dopo le summaries, i dettagli completano in background
con StateHasChanged() per aggiornare l'UI istantaneamente.
- Fix scheduler - preservazione ExternalIdRelationshipsJson e DefaultValuesJson:
in DataCoupler.razor.cs entrambi i blocchi di update profilo esistente
(riattivazione profilo inattivo e sovrascrittura profilo attivo) omettevano
questi campi nella copia, causandone l'azzeramento silenzioso ad ogni
re-salvataggio. Ora entrambi i percorsi propagano correttamente i campi JSON.
- Fix scheduler - esclusione campi sorgente External ID dal mapping normale:
in ScheduledProfileExecutionService.TransformRecordForRest i campi sorgente
usati nelle External ID Relationships venivano inclusi anche nel loop di
field mapping standard, generando dati duplicati nell'entita' destinazione.
Ora il comportamento e' allineato alla UI manuale (TransformRecordToRestEntity).
- Aggiornata documentazione: README.md, AGENTS.md, copilot-instructions.md
- Disabilitato target MSBuild GenerateVersionJson durante build CI/CD
- Aggiunta condizione: non esegue se ContinuousIntegrationBuild=true
- Aggiornato Dockerfile per usare /p:ContinuousIntegrationBuild=true
- Previene sovrascrittura del version.json generato dal workflow Gitea
- Risolve problema: container mostra v1.0.0-dev invece della versione da git tag
- Cambiato immagine base da Alpine a Debian per migliore compatibilità SQLite
- Aggiunto SQLitePCLRaw.bundle_e_sqlite3 per librerie native cross-platform
- Installato sqlite3 e libsqlite3-dev in Debian
- Risolve definitivamente: 'Error loading shared library libe_sqlite3.so'
- Aggiunto MSBuild target che genera version.json automaticamente prima di ogni build
- Versione estratta dal tag git più recente (git describe --tags)
- Rimosso version.json dal tracking git (file generato automaticamente)
- Aggiornato .gitignore per escludere version.json
- Il file viene ora rigenerato ad ogni build con versione, commit SHA, branch e timestamp corretti
- Aggiunto --runtime win-x64 al comando restore
- Specificato -r win-x64 --self-contained false nella publish
- Il restore ora genera project.assets.json per net9.0/win-x64
- Sintassi corretta: --self-contained false invece di /p:SelfContained=false
- Sostituito /p:UseAppHost=false con /p:SelfContained=false in entrambi i Dockerfile
- .NET 9.0 richiede AppHost per applicazioni self-contained
- SelfContained=false è appropriato per container Docker con runtime separato
- Fix applicato sia a Dockerfile (Linux) che Dockerfile.windows
- Creato modello FieldMappingEntry per gestione unificata di field mapping e default values
- Aggiunta colonna DefaultValuesJson alla tabella DataCouplerProfile (max 4000 caratteri)
- Implementata UI con toggle per selezionare modalità Mapping o Default
- Supporto per 9 tipi di dati: string, int, long, decimal, double, float, boolean, datetime, datetimeoffset
- Aggiornata logica TransformRecordToRestEntity per applicare valori default dopo field mapping
- Implementata serializzazione/deserializzazione DefaultValues in DataCouplerProfileService
- Sistema completo di salvataggio/caricamento valori default nei profili
- Migrazione database AddDefaultValuesJsonToProfile creata e applicata
- Implementata funzionalità completa External ID Relationships nell'interfaccia di mapping
- Corretto bug double-mapping: i campi sorgente usati per External ID non vengono più inclusi nei mapping normali
- Risolto errore MALFORMED_ID causato dall'invio duplicato di campi come proprietà dirette e nested objects
- Implementata logica corretta per relationship names: oggetti standard usano il nome diretto, custom objects usano suffisso __r
- Aggiunta UI a 3 colonne (Object, External ID Field, Source Field) per configurazione External ID Relationships
- Migrazione database per supporto External ID Relationships nei profili
- Aggiornato ProfileSaver.razor.cs per salvare/caricare External ID Relationships
- Aggiornato ScheduledProfileExecutionService.cs per gestire External ID nelle esecuzioni schedulate
- Formato JSON output corretto: { 'Account': { 'CardCode__c': 'V50000' } }
Documentazione: EXTERNAL_ID_RELATIONSHIPS_IMPLEMENTATION.md
- Disabilitato trimming per compatibilità con Blazor Server (risolve crash TypeLoadException)
- Configurati PublishSingleFile e ReadyToRun per deployment ottimizzato
- Rimosso controllo eccessivamente restrittivo sui commenti SQL in validazione query
- Ora permessi commenti -- e /* */ nelle query SELECT ODBC
- Mostra stato di tutte le variabili che controllano la visibilità del mapping
- Indica quale condizione non è soddisfatta (isSourceReady, isRestConnected, selectedRestEntity)
- Pannello visibile solo per connessioni ODBC
- Aiuta a identificare rapidamente il problema
- Modificata condizione isSourceReady in DataCoupler.razor
- Per ODBC: richiede solo useCustomQuery && isQueryValid (non isDatabaseConnected)
- Per altri DB: comportamento invariato (richiede isDatabaseConnected)
- Risolto: mapping non appariva dopo validazione query ODBC
- Modificato OnDatabaseCredentialChanged per rilevare connessioni ODBC e forzare useCustomQuery = true
- Aggiunto metodo helper IsOdbcConnection() per verificare tipo credenziale
- Modificata UI DataCoupler.razor:
* Nascosto pulsante 'Connetti e Scopri Schema' per ODBC
* Mostrato messaggio esplicativo per ODBC
* Resa sezione Query Custom sempre visibile per ODBC (senza discovery)
* Nascosta sezione Lista Tabelle per ODBC
- Modificato ValidateCustomQuery per creare temporaneamente DatabaseManager per ODBC
- ODBC ora bypassa completamente il discovery e va diretto a query custom
- Aggiunta persistenza campi ODBC (OdbcDsnName, OdbcMode) in CredentialEntity
- Creata migration EF Core per nuovi campi database
- Aggiornato mapping credenziali per caricare/salvare dati ODBC
- Creato OdbcDatabaseManager dedicato (bypass EF Core che non supporta ODBC)
- Aggiornato DataConnectionFactory per usare OdbcDatabaseManager con connessioni ODBC
- Fix auto-load DSN: sostituito @onchange con @bind-Value:after in dropdown tipo database
- Fix test connessione SAP HANA: rimossa query SELECT 1 che causava errori sintassi
- Implementati tutti i metodi IDatabaseManager in OdbcDatabaseManager
- Supporto completo per discovery schema, tabelle e query ODBC
Risolve problema DbContext non configurato per ODBC e abilita connessioni ODBC complete.
- Rimosso tag 'latest' da branch development, staging e dev
- Tag 'latest' ora riservato esclusivamente al branch main
- Altri branch mantengono tag specifici (development-latest, staging-latest, dev-latest)
- Modificati workflow GitHub Actions e Gitea Actions
- Semplifica la gestione delle versioni in produzione vs sviluppo
Alessio Dal Santo
Alessio