Come risolvere l’errore Oracle ORA-01408 su Liferay
Sviluppi “felicemente” su Liferay 7/DXP e tutto funziona correttamente sul tuo ambiente locale. Quando arriva il fatidico momento del deploy in ambienti diversi dal tuo, qualcuno ti chiama dicendoti che il tuo bundle non funziona e sui log vede quest’errore:
ORA-01408: esiste già un indice per questa lista di colonne: create index IX_1118FBD3 on lbro_horse_Horse (horseId);
La tua prima risposta è: ma sul mio ambiente locale funziona! e dall’altro lato ti senti rispondere: si, ma sul tuo ambiente locale non hai installato oracle database.
Qualche giorno addietro mi son trovato proprio dentro questa scenetta; riuscire a capire la causa e trovare poi la soluzione senza sconvolgere tutto non è stato affatto semplice.
1. Affrontiamo il maledetto ORA-01408
L’errore Oracle ORA-01408 a fronte dell’esecuzione dell’istruzione CREATE INDEX, informa che esiste già un indice per la colonna specificata. Il codice SQL per il database è generato da Liferay, compreso quello della gestione degli indici, ergo, la colpa dell’errore è di Liferay. In realtà Liferay (e in particolare il Service Builder) non c’entra nulla, vedremo il perché e come risolvere questo odiosissimo e bloccante problema.
Prendiamo in esame la descrizione dell’entità Horse definita all’interno del file service.xml. La riga 10 definisce la chiave primaria dell’entità e il blocco di righe 33-35 definisce invece il finder HorseIds, quest’ultimo consente di ottenere una collezioni di oggetti di tipo Horse specificando una lista di horseId.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
<?xml version="1.0"?> <!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 7.0.0//EN" "http://www.liferay.com/dtd/liferay-service-builder_7_0_0.dtd"> <service-builder package-path="it.dontesta.labs.liferay.lrbo16.servicebuilder"> <namespace>LRBO_HORSE</namespace> <entity local-service="true" name="Horse" remote-service="true" uuid="true"> <!-- PK fields --> <column name="horseId" primary="true" type="long" /> <!-- Group instance --> <!-- Audit fields --> <!-- Other fields --> <column name="name" type="String" /> <column name="age" type="int" /> <column name="gender" type="String" /> <column name="kind" type="String" /> <column name="mantle" type="String" /> <!-- Order --> <order by="asc"> <order-column name="name" /> </order> <!-- Finder methods --> <finder name="HorseIds" return-type="Collection"> <finder-column name="horseId" arrayable-operator="OR" comparator="="/> </finder> <finder name="Name" return-type="Collection"> <finder-column name="name" /> </finder> </entity> </service-builder> |
Per i nostri finder il processo di build service genera le opportune istruzioni di creazione degli indici. Secondo quanto definito su questo specifico service.xml, il file indexes.sql presenta il seguente contenuto:
|
1 2 3 4 5 |
create index IX_1CD9D1BA on LRBO_HORSE_Horse (age); create index IX_1118FBD3 on LRBO_HORSE_Horse (horseId); create index IX_943F5AD4 on LRBO_HORSE_Horse (name[$COLUMN_LENGTH:75$]); create index IX_12A69589 on LRBO_HORSE_Horse (uuid_[$COLUMN_LENGTH:75$], companyId); create unique index IX_16B8EA4B on LRBO_HORSE_Horse (uuid_[$COLUMN_LENGTH:75$], groupId); |
La riga 2 mostra l’istruzione di creazione dell’indice per la colonna horseId che in questo caso è anche la chiave primaria dell’entità Horse. Fate attenzione al nome dell’indice specificato nell’istruzione di riga 2 (IX_1118FBD3), è proprio quello menzionato dall’errore restituito da Oracle.
Il contenuto del file indexes.sql presenta un sola istruzione di creazione dell’indice per la colonna horseId. A questo punto la domanda è spontanea: chi crea l’indice per la colonna horseId?
Ricordiamo che la colonna horseId è definita come chiave primaria, e in questi casi, in modo implicito il database crea un indice univoco per la chiave; è lecito quindi da parte del database sollevare l’eccezione ORA-01408.
2. Risolviamo il maledetto ORA-01408
Molto bene! Adesso che siamo a conoscenza del motivo che genera l’errore ORA-01408, il prossimo passo è quello di trovare una soluzione semplice da applicare per risolvere il problema. Sono sicuro che tutti voi vi starete chiedendo:
Possibile che Liferay non abbia pensato al modo per risolvere questo problema? Possibile che non esista un modo per evitare la creazione degli indici?
Purtroppo la documentazione ufficiale di Liferay non risponde alle nostre domande, non disperiamo però, perché il DTD del service.xml ha la risposta al suo interno.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
<!-- The name value specifies the name of the finder method. The return-type value specifies the return type of the finder. Valid values are "Collection" or the name of the entity. If the value is "Collection", then this finder returns a list of entities. If the value is the name of the entity, then this finder returns at most one entity. If the unique value is true, then the finder must return a unique entity. If the db-index value is true, then the service will automatically generate a SQL index for this finder. The default value is true. --> <!ATTLIST finder name CDATA #REQUIRED return-type CDATA #REQUIRED unique CDATA #IMPLIED where CDATA #IMPLIED db-index CDATA #IMPLIED > |
L’attributo db-index sull’elemento finder è la risposta al nostro problema. Il valore di default è true, noi aggiungeremo l’attributo db-index all’elemento finder impostando il valore a false, lanciando subito dopo il processo di build service (ma dopo aver eliminato il vecchio file indexes.sql). Esaminando il file indexes.sql subito dopo l’esecuzione del processo build service, scopriamo con grande felicità che l’istruzione di create index per la colonna horseId è sparita.
|
1 2 3 4 |
create index IX_1CD9D1BA on LRBO_HORSE_Horse (age); create index IX_943F5AD4 on LRBO_HORSE_Horse (name[$COLUMN_LENGTH:75$]); create index IX_12A69589 on LRBO_HORSE_Horse (uuid_[$COLUMN_LENGTH:75$], companyId); create unique index IX_16B8EA4B on LRBO_HORSE_Horse (uuid_[$COLUMN_LENGTH:75$], groupId); |
A questo punto consegniamo il nostro bundle “all’omino” (per esempio Jenkins) responsabile del deploy in ambiente con Oracle database, con la certezza che tutto andrà a buon fine.
