Entitymanager works chaotically, do not merge in some cases - eclipselink

Seriously, i cannot believe this:
I use entityManager in Vaadin framework. Implemented this pattern (ThreadLocal and filter for generating entityManager for every request):
https://vaadin.com/book/-/page/jpacontainer.hibernate.html
If i write a test it is works like charm:
EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory("applicLiquidator.applicLiquidator");
log.trace("created entityManageFactory:" + entityManagerFactory);
EntityManager entityManager = entityManagerFactory.createEntityManager();
CaseEntity case= entityManager.getReference(CaseEntity .class, 1);
entityManager.detach(case);
case.setCompanyFullName("TEST1");
entityManager.getTransaction().begin();
CaseEntity newCase=entityManager.merge(case);
entityManager.getTransaction().commit();
However in the application server it works entirely other way, i logged ever information and seems everything is OK, the entity has the good values!
public static int saveCase(CaseEntity case, boolean sameTransaction) throws DALException {
EntityTransaction transaction = null;
try {
EntityManager entityManager = EntityManagerUtil.getEntityManagerLIQUIDATOR();
if (sameTransaction == false) {
transaction = entityManager.getTransaction();
transaction.begin();
}
log.info("-------BEFORE PERSIST: CASE ENTTIY COMAPNY NAME: " + ugy.getFelszamolandoCegTeljesnev());
ugy=entityManager.merge(ugy);
if (sameTransaction == false) {
transaction.commit();
}
log.info("---------AFTER PERSIST: CASE ENTTIY COMAPNY NAME: " + ugy.getFelszamolandoCegTeljesnev());
return case.getId();
} catch (Exception ex) {
log.error("The entity saved do not completed", ex);
try {
transaction.rollback();
log.info("Rollback was success");
} catch (Exception rollbex) {
log.error("Rollback failed", rollbex);
}
log.info("Entity Saved succesfully!");
throw new DALException(ex);
}
}
As you can see, i tried refresh, clear, flush everything. Important to note here that case is a detached object, but as far as i know merge will do the job but the reference will not copied to the original object, but will (should) update the entity with the same id...
In other cases (with other entites this code is works like charm), only with one case, the first one entity at the database with id 1 is making bug!
I cannot understand why it is, why it is working some cases, and why it is not... And why it is that i see the good values in the entity attibutes and it just doesn't generate the update sql and doesn't make the merge/update in the persistance context and also at the database, no error message, nothing to show, only missfunction...
If anyone ever experience this kind of mistic bug/issue i would more than appreciate the answer or any slight idea, anything came in to your mind pls take time to answer.
Log when try to merge entity:
2014-01-21 17:36:11 TRACE LazyEntityManagerFilter:44 - created entityManager:org.eclipse.persistence.internal.jpa.EntityManagerImpl#7b1fe9fb
2014-01-21 17:36:11 WARN UgyController:667 - Event detected private void notImplemented()
2014-01-21 17:36:11 TRACE LazyEntityManagerFilter:51 - destroyed entityManager:org.eclipse.persistence.internal.jpa.EntityManagerImpl#7b1fe9fb
2014-01-21 17:36:11 TRACE LazyEntityManagerFilter:44 - created entityManager:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.387--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, becsultertek, bekerulesidopontja, devizanem, ingosagazonosito, kikerulesidopontja, kikerulesiertek, letrehozva, megnevezes, memo, tarolasihely, telephelyenbelulihelye, tranzakcioskod, utoljaramod_mikor, telephely_felszamolando_ID, ingosagcsoport_ID, utoljaramodositotta_felhasznalo_ID FROM liquidator.ingosag WHERE (telephely_felszamolando_ID = ?)
bind => [1]
[EL Fine]: 2014-01-21 17:36:11.389--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, csoportnev, letrehozva, lockideje, tranzakcioskod, utoljaramod_mikor, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ingosagcsoport WHERE (ID = ?)
bind => [1]
[EL Fine]: 2014-01-21 17:36:11.392--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, csoportnev, letrehozva, lockideje, tranzakcioskod, utoljaramod_mikor, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ingosagcsoport WHERE (ID = ?)
bind => [2]
[EL Fine]: 2014-01-21 17:36:11.394--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, bejelentkezesidopontja, bejelentkezesinev, email, jelszo, keresztnev, kilepesideje, letrehozva, lockideje, memo, sessionlejarat, szerepkor, telefon, tranzakcioskod, utoljaramod_mikor, vezeteknev, cim_ID, utoljaramodositotta_felhasznalo_ID, bejelentkezes_telephelyId, lockbyfelhasznalo_ID FROM liquidator.felhasznalo WHERE (ID = ?)
bind => [3]
[EL Fine]: 2014-01-21 17:36:11.398--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, fajlnev, kiskeptartalom, letrehozva, memo, mimetype, nincskep, tartalom, tranzakcioskod, utoljaramod_mikor, ingosag_ID, utoljaramodositotta_felhasznalo_ID FROM liquidator.kep WHERE (ingosag_ID = ?)
bind => [1]
[EL Fine]: 2014-01-21 17:36:11.4--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, fajlnev, kiskeptartalom, letrehozva, memo, mimetype, nincskep, tartalom, tranzakcioskod, utoljaramod_mikor, ingosag_ID, utoljaramodositotta_felhasznalo_ID FROM liquidator.kep WHERE (ingosag_ID = ?)
bind => [2]
[EL Fine]: 2014-01-21 17:36:11.401--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, becsultertek, bekerulesidopontja, devizanem, ingosagazonosito, kikerulesidopontja, kikerulesiertek, letrehozva, megnevezes, memo, tarolasihely, telephelyenbelulihelye, tranzakcioskod, utoljaramod_mikor, telephely_felszamolando_ID, ingosagcsoport_ID, utoljaramodositotta_felhasznalo_ID FROM liquidator.ingosag WHERE (telephely_felszamolando_ID = ?)
bind => [2]
[EL Fine]: 2014-01-21 17:36:11.402--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, becsultertek, bekerulesidopontja, devizanem, ingosagazonosito, kikerulesidopontja, kikerulesiertek, letrehozva, megnevezes, memo, tarolasihely, telephelyenbelulihelye, tranzakcioskod, utoljaramod_mikor, telephely_felszamolando_ID, ingosagcsoport_ID, utoljaramodositotta_felhasznalo_ID FROM liquidator.ingosag WHERE (telephely_felszamolando_ID = ?)
bind => [3]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.404--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, belsougyiratszam, elrendeles_doc_fajlnev, elrendeles_doc_memo, elrendeles_doc_mimetype, elrendeles_doc_tartalom, elrendeles_idopontja, elrendeles_ki, elrendeles_memo, felszamolando_ceg_adoszam, felszamolando_ceg_cegjegyzekszam, felszamolando_ceg_memo, felszamolando_ceg_rovidnev, felszamolando_ceg_teljesnev, kozzeteteldatuma, kulsougyiratszam, letrehozva, lockideje, memo, tranzakcioskod, utoljaramod_mikor, zarovegzesdatuma, elrendeles_felhasznalo_ID, ugy_felhasznalo_ID, felszamolando_ceg_cim_ID, telephely_ID, statusz_ID, ugytipus_ID, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugy WHERE ((ID = ?) AND (aktiv = ?))
bind => [7, true]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.41--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, letrehozva, lockideje, statusz, tranzakcioskod, utoljaramod_mikor, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugystatusz WHERE (aktiv = ?)
bind => [true]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.413--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT DISTINCT f.* FROM felhasznalo f,telephely, felhasznalougyintezo_telephely ftu WHERE f.aktiv = 1 AND telephely.ID = ? AND telephely.aktiv = 1 AND f.ID = ftu.felhasznalo_ID AND ftu.telephely_ID = ?
bind => [1, 1]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.418--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, letrehozva, lockideje, tipus, tranzakcioskod, utoljaramod_mikor, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugytipus WHERE (aktiv = ?)
bind => [true]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.421--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT DISTINCT f.* FROM felhasznalo f,telephely, felhasznalougyintezo_telephely ftu WHERE f.aktiv = 1 AND telephely.ID = ? AND telephely.aktiv = 1 AND f.ID = ftu.felhasznalo_ID AND ftu.telephely_ID = ?
bind => [1, 1]
telephelyTelephely A
telephelyTelephely B
telephelyTelephely (törölt)
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.449--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.felhasznalo SET bejelentkezes_telephelyId = ? WHERE (ID = ?)
bind => [1, 9999999]
[EL Fine]: 2014-01-21 17:36:11.45--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ?, utoljaramodositotta_felhasznalo_ID = ? WHERE (ID = ?)
bind => [8d7b4195-38f3-4ba6-ab13-2840de6291d4, 2014-01-21 17:36:11.384, 9999999, 1]
[EL Fine]: 2014-01-21 17:36:11.452--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ?, utoljaramodositotta_felhasznalo_ID = ? WHERE (ID = ?)
bind => [8d7b4195-38f3-4ba6-ab13-2840de6291d4, 2014-01-21 17:36:11.384, 9999999, 2]
[EL Fine]: 2014-01-21 17:36:11.453--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ?, utoljaramodositotta_felhasznalo_ID = ? WHERE (ID = ?)
bind => [8d7b4195-38f3-4ba6-ab13-2840de6291d4, 2014-01-21 17:36:11.384, 9999999, 3]
[EL Fine]: 2014-01-21 17:36:11.467--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.ingosag SET tranzakcioskod = ?, utoljaramod_mikor = ?, utoljaramodositotta_felhasznalo_ID = ? WHERE (ID = ?)
bind => [8d7b4195-38f3-4ba6-ab13-2840de6291d4, 2014-01-21 17:36:11.384, 9999999, 1]
[EL Fine]: 2014-01-21 17:36:11.468--ClientSession(1062469667)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--UPDATE liquidator.ingosag SET tranzakcioskod = ?, utoljaramod_mikor = ?, utoljaramodositotta_felhasznalo_ID = ? WHERE (ID = ?)
bind => [8d7b4195-38f3-4ba6-ab13-2840de6291d4, 2014-01-21 17:36:11.384, 9999999, 2]
2014-01-21 17:36:11 INFO UgyController$UgyPersistor:978 - UgyEntity módosítása a DB-ben sikeres. UgyEntityID: 7
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.524--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, belsougyiratszam, elrendeles_doc_fajlnev, elrendeles_doc_memo, elrendeles_doc_mimetype, elrendeles_doc_tartalom, elrendeles_idopontja, elrendeles_ki, elrendeles_memo, felszamolando_ceg_adoszam, felszamolando_ceg_cegjegyzekszam, felszamolando_ceg_memo, felszamolando_ceg_rovidnev, felszamolando_ceg_teljesnev, kozzeteteldatuma, kulsougyiratszam, letrehozva, lockideje, memo, tranzakcioskod, utoljaramod_mikor, zarovegzesdatuma, elrendeles_felhasznalo_ID, ugy_felhasznalo_ID, felszamolando_ceg_cim_ID, telephely_ID, statusz_ID, ugytipus_ID, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugy WHERE ((ID = ?) AND (aktiv = ?))
bind => [7, true]
2014-01-21 17:36:11 INFO UgyController$UgyPersistor:998 - Ügy egészének perzisztálása sikeres. UgyEntityID: 7
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.528--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, belsougyiratszam, elrendeles_doc_fajlnev, elrendeles_doc_memo, elrendeles_doc_mimetype, elrendeles_doc_tartalom, elrendeles_idopontja, elrendeles_ki, elrendeles_memo, felszamolando_ceg_adoszam, felszamolando_ceg_cegjegyzekszam, felszamolando_ceg_memo, felszamolando_ceg_rovidnev, felszamolando_ceg_teljesnev, kozzeteteldatuma, kulsougyiratszam, letrehozva, lockideje, memo, tranzakcioskod, utoljaramod_mikor, zarovegzesdatuma, elrendeles_felhasznalo_ID, ugy_felhasznalo_ID, felszamolando_ceg_cim_ID, telephely_ID, statusz_ID, ugytipus_ID, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugy WHERE (aktiv = ?)
bind => [true]
2014-01-21 17:36:11 INFO EntityManagerUtil:46 - entityManager object name#hascode:org.eclipse.persistence.internal.jpa.EntityManagerImpl#6c3a9ce3
[EL Fine]: 2014-01-21 17:36:11.54--ServerSession(2071159129)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-19,5,main])--SELECT ID, aktiv, belsougyiratszam, elrendeles_doc_fajlnev, elrendeles_doc_memo, elrendeles_doc_mimetype, elrendeles_doc_tartalom, elrendeles_idopontja, elrendeles_ki, elrendeles_memo, felszamolando_ceg_adoszam, felszamolando_ceg_cegjegyzekszam, felszamolando_ceg_memo, felszamolando_ceg_rovidnev, felszamolando_ceg_teljesnev, kozzeteteldatuma, kulsougyiratszam, letrehozva, lockideje, memo, tranzakcioskod, utoljaramod_mikor, zarovegzesdatuma, elrendeles_felhasznalo_ID, ugy_felhasznalo_ID, felszamolando_ceg_cim_ID, telephely_ID, statusz_ID, ugytipus_ID, utoljaramodositotta_felhasznalo_ID, lockbyfelhasznalo_ID FROM liquidator.ugy WHERE ((ID = ?) AND (aktiv = ?))
bind => [7, true]
But when i want to save/merge another entity (e.g. ID 1303), the insert is nicely generated and executed:
[EL Fine]: 2014-01-21 17:38:19.391--ClientSession(1093415948)--Connection(264299847)--Thread(Thread[http-bio-8080-exec-22,5,main])--UPDATE liquidator.ugy SET felszamolando_ceg_teljesnev = ?, lockideje = ?, tranzakcioskod = ?, utoljaramod_mikor = ?, lockbyfelhasznalo_ID = ? WHERE (ID = ?)
bind => [akgalkgsafafsTESTESTUJUJ, null, 52254092-4954-441f-922c-8c5527b9dd9a, 2014-01-21 17:38:19.368, null, 1303]
LOG UPDATE WITH NEW CODE
2014-01-21 17:55:19 INFO UgyDAO:162 - -------BEFORE PERSIST: CASE ENTTIY COMAPNY NAME: NEW COMPANY NAME
[EL Fine]: 2014-01-21 17:55:19.19--ClientSession(1760590618)--Connection(392035700)--Thread(Thread[http-bio-8080-exec-46,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ? WHERE (ID = ?)
bind => [fe48707b-5064-49c5-81bf-d1f78cd93126, 2014-01-21 17:55:19.156, 1]
[EL Fine]: 2014-01-21 17:55:19.194--ClientSession(1760590618)--Connection(392035700)--Thread(Thread[http-bio-8080-exec-46,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ? WHERE (ID = ?)
bind => [fe48707b-5064-49c5-81bf-d1f78cd93126, 2014-01-21 17:55:19.156, 2]
[EL Fine]: 2014-01-21 17:55:19.197--ClientSession(1760590618)--Connection(392035700)--Thread(Thread[http-bio-8080-exec-46,5,main])--UPDATE liquidator.telephely_felszamolando SET tranzakcioskod = ?, utoljaramod_mikor = ? WHERE (ID = ?)
bind => [fe48707b-5064-49c5-81bf-d1f78cd93126, 2014-01-21 17:55:19.156, 3]
[EL Fine]: 2014-01-21 17:55:19.198--ClientSession(1760590618)--Connection(392035700)--Thread(Thread[http-bio-8080-exec-46,5,main])--UPDATE liquidator.ingosag SET tranzakcioskod = ?, utoljaramod_mikor = ? WHERE (ID = ?)
bind => [fe48707b-5064-49c5-81bf-d1f78cd93126, 2014-01-21 17:55:19.156, 1]
[EL Fine]: 2014-01-21 17:55:19.201--ClientSession(1760590618)--Connection(392035700)--Thread(Thread[http-bio-8080-exec-46,5,main])--UPDATE liquidator.ingosag SET tranzakcioskod = ?, utoljaramod_mikor = ? WHERE (ID = ?)
bind => [fe48707b-5064-49c5-81bf-d1f78cd93126, 2014-01-21 17:55:19.156, 2]
2014-01-21 17:55:19 INFO UgyDAO:168 - ---------AFTER PERSIST: CASE ENTTIY COMAPNY NAME: UJ TELJES NEV!

I very believe however yet no time to POC/test it, but my problem was caused because the poorly implemented hashcode() and equals() methods!
As it seems reference this article:
http://tmjee.blogspot.hu/2012/11/do-we-need-equals-and-hashcode.html
That poor hashcode implementation can cause merge problems in detached objects, and that is exactly my issue.

Related

Apache Isis Action to list entities is too slow, found 2 issues/questions on it

Use demo app PetClinic as an example. Only focus on PetOwner, no other entities. Some pet owners are pre-inserted to the db.
The action "listAll" in the demo:
#Action(semantics = SemanticsOf.SAFE)
#ActionLayout(bookmarking = BookmarkPolicy.AS_ROOT)
public List<PetOwner> listAll() {
return petOwnerRepository.findAll();
}
When action "listAll" is called, we find two issues/questions related to the delay.
Lots of queries are going out, one for each entity
this is the query goes to jpa that makes sense
[EL Fine]: sql: 2022-03-10 14:50:50.303--ClientSession(1477740542)--Connection(716488272)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER
and there are more queries coming:
[EL Fine]: sql: 2022-03-10 14:50:50.436--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [1]
[EL Fine]: sql: 2022-03-10 14:50:50.437--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [2]
[EL Fine]: sql: 2022-03-10 14:50:50.437--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [3]
[EL Fine]: sql: 2022-03-10 14:50:50.437--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [4]
[EL Fine]: sql: 2022-03-10 14:50:50.438--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [5]
[EL Fine]: sql: 2022-03-10 14:50:50.438--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [6]
[EL Fine]: sql: 2022-03-10 14:50:50.438--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [7]
[EL Fine]: sql: 2022-03-10 14:50:50.438--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [8]
[EL Fine]: sql: 2022-03-10 14:50:50.439--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [9]
[EL Fine]: sql: 2022-03-10 14:50:50.439--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [10]
[EL Fine]: sql: 2022-03-10 14:50:50.439--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [11]
[EL Fine]: sql: 2022-03-10 14:50:50.44--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [12]
[EL Fine]: sql: 2022-03-10 14:50:50.44--ClientSession(840311416)--Connection(1724151743)--SELECT id, NAME, NOTES, version FROM pets.PETOWNER WHERE (id = ?)
bind => [13]
is there any config/setting inside Apache Isis to not make those queries? since from the first query I assume we already got everything right?
We still see delay even without those queries.
So to solve the issue, we introduced a DTO class as view model to decouple domain entities from the list results
DTO class:
#DomainObject(nature = Nature.VIEW_MODEL,logicalTypeName = "cps.PetOwnerDtoViewModel")
#XmlRootElement(name = "PetOwnerDtoViewModel")
#XmlAccessorType(XmlAccessType.FIELD)
#XmlType(
propOrder = {
"name",
"notes"
}
)
public class PetOwnerDto {
private String name;
private String notes;
...(constructor and getter setter)
}
and wrapped a list of DTOs into another viewmodel because we need to add action against collection later. (as suggested here ISIS: Moving from deprecated #Action(invokeOn=...) to #Action(associateWith=...))
#DomainObject(nature = Nature.VIEW_MODEL,logicalTypeName = "cps.PetOwnersViewModel")
#XmlRootElement(name = "PetOwnersViewModel")
#XmlAccessorType(XmlAccessType.FIELD)
#XmlType(
propOrder = {
"petOwnerList"
}
)
#NoArgsConstructor(access = AccessLevel.PUBLIC)
public class PetOwnersViewModel {
public String title() {
return "Owners";
}
#XmlElementWrapper
#XmlElement(name = "petOwnerList")
#Getter
#Setter
#CollectionLayout(paged = 5)
protected List<PetOwnerDto> petOwnerList = new LinkedList<>();
public PetOwnersViewModel(List<PetOwnerDto> results) {
this.petOwnerList = results;
}
}
And we created a new action to return PetOwnerViewModel:
#Action(semantics = SemanticsOf.SAFE)
#ActionLayout(bookmarking = BookmarkPolicy.AS_ROOT)
public PetOwnersViewModel listAllDto() {
List<PetOwner> petOwnerList = petOwnerRepository.findAll();
LinkedList<PetOwnerDto> petOwnerDtos = new LinkedList<>();
for (PetOwner p : petOwnerList) {
petOwnerDtos.add(new PetOwnerDto(p));
}
return new PetOwnersViewModel(petOwnerDtos);
}
This way there is only one query goes out to db, no extra queries are found.
Then we loaded the db with 1000 pet owners. with #CollectionLayout(paged = 5) in place, the delay is still there but acceptable, but if we click "show all", it takes 20 seconds to show all 1000 rows' data. Is there any reason this operation takes so long? Since all the needed data is already pulled from db right?
Thanks, hope anyone can help!
Formally this is not an answer (just a comment):
Thanks for reporting your observations here! I did open a Jira ticket for further investigation:
https://issues.apache.org/jira/browse/ISIS-2973

ProcessMaker get data from SqlServer returned error

I am going to bind a dropdown from Sql Server database in ProcessMaker DynaForm. I set up the connection and write the query. My query return data which some of them are in Persian language, so the dropdown failed to bind and Chrome Inspector shows the error:
Unexpected token ;
Whenever I changed my query in which the returned data is not in Perisan language, every thing works fine!
Even when I write a mock query such as: Select 1, N'وحید', whitout referencing any table, every thing works fine too!
How can I confugre processmaker to show the Persian language data in dropdown too?
UPDATE
I found the php class which executes the query and get the returned data. Here is the result which is returned:
Array ( [0] => 1 [1] => ��� ����� )
Array ( [0] => 2 [1] => ��� �Ә��� )
Array ( [0] => 3 [1] => ��� ������� )
Array ( [0] => 4 [1] => ������ )
Array ( [0] => 5 [1] => ��� ͘�� )
I think there is some problem with connection encoding, but I do not know how to resolve it!
Here is my connection to sql server's details:
MSSQLStatement Object ( [conn:protected] => MSSQLConnection Object ( [database:MSSQLConnection:private] => MyDB [transactionOpcount:protected] => 0 [dblink:protected] => Resource id #18 [dsn:protected] => Array ( [database] => MyDB [encoding] => utf8 [hostspec] => MyInstanceName [password] => MyPassword [phptype] => mssql [port] => [protocol] => [socket] => [username] => MyUserName ) [flags:protected] => 0 [lastQuery] => select Id, Title From MyTable ) [resultSet:protected] => [updateCount:protected] => [warnings:protected] => Array ( ) [resultClass:protected] => [stmt:protected] => [limit:protected] => 0 [offset:protected] => 0 )
Are you adding a semicolon at the end of the query?
If you checkout the ProcessMaker documentation, they indicate that when using SQL server, semicolon should not be added:

Cakephp: find in a controller using "like" inside an array of possible values

The main idea of this post is that I need to combine search inside an array via "like" without doing a fetch.
In the following code I extract the zones (part of postal code) depending on session ID:
$sess_id = $this->Session->read('Auth.User');
$this->loadModel('Zone', 2);
$MyZones = $this->Zone->find('list', array('recursive' => -1, 'conditions' => array('Zone.user_id' => $sess_id['id']), 'fields' => array('Zone.zone')));
$this->set('MyZones', $MyZones);
print_r($MyZones);
//output : $MyZone = Array ( [1] => AB [2] => AL [3] => B1 )
Now that I have my array I want to look for persons who live in this zone (example his postalcode can be AB526PQ so he lives in the administrator zone)
$this->loadModel('Person', 2);
$num_persons = $this->Person->find('count', array('recursive' => -1, 'conditions' => array('Person.pc LIKE' => '%' . $MyZones)));
$this->set('num_persons', $num_persons);
I got the following error :
Notice (8): Array to string conversion [APP\Controller\ZonesController.php]
This is the generated sql query:
SELECT COUNT(*) AS `count` FROM `tn`.`personnes` AS `Personne` WHERE `Personne`.`pc` LIKE '%Array'
You will have to break your condition from
$conditions = array('Person.pc LIKE' => '%' . $MyZones);
to
foreach($MyZones as $MyZone) {
$conditions[] = array('Person.pc LIKE' => '%' . $MyZone);
}

how to get result for api connecting to whoapi?

As according to the mention documentation at whoapi.com i have gone through as mention according to instruction and tried implementing the api but the variable doesn't pass from one page to other.For example i have one page which have input type and submit button then when i click submit button it should redirect to who api url and display result
http://api.whoapi.com/?domain=whoapi.com&apikey=demokey&r=blacklist
whoapi.com = name of url,demokey = key assigned by who api & blacklist = name of service of who api
guide me through the connecting protocol.
Not sure I understand the question. Using the API should be straight simple as any REST request is.
PHP example:
$domain = "whoapi.com";
$r = "blacklist";
$apikey = "demokey";
$request = "http://api.whoapi.com/?domain=$domain&r=$r&apikey=$apikey";
$output = json_decode(file_get_contents($request), true);
Resulting array with print_r($output) looks like this:
[status] => 0
[ip] => 88.198.98.181
[blacklisted] => 0
[blacklists] => Array
(
[0] => Array
(
[tracker] => invaluement.com
[blacklisted] => 0
)
[1] => Array
(
[tracker] => surbl.org
[blacklisted] => 0
)
[2] => Array
(
[tracker] => barracudacentral.org
[blacklisted] => 0
)
[3] => Array
(
[tracker] => sorbs.net
[blacklisted] => 0
)
[4] => Array
(
[tracker] => spamhaus.org
[blacklisted] => 0
)
)
Hope this helps.

PDO::FETCH_ASSOC Does not return the correct table columns

I'm new to PHP and I am currently developing a small web application. Below is the test code for the DB query using PDO:
try
{
$dsn = "mysql:host=localhost;dbname=auction";
$opt = array(
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'"
);
$pdo = new PDO($dsn, 'root', 'password', $opt);
}
catch(PDOException $e)
{
echo $e->getMessage();
}
$stmt = $pdo->query("SELECT id,username,password,name,level FROM users");
$stmt->setFetchMode(PDO::FETCH_ASSOC);
$test = $stmt->fetchALL();
print_r($test);
The output of the said code is the following:
Array ( [0] => Array ( [id] => 1 [username] => admin [users] => Administrator [auction] => 0 )
[1] => Array ( [id] => 2 [username] => jodel [users] => Jodel Ross [auction] => 1 ) )
I am confused because, from my point of view, the above code should have given an associative array whose index are the columns of the returned result set, i.e. id, username,password,name,level. But it is not so.
Moreover, If I used PDO::FETCH_NUM, the correct number of fields and corresponding data are returned correctly as show below:
Array ( [0] => Array ( [0] => 1
[1] => admin
[2] => 21232f297a57a5a743894a0e4a801fc3
[3] => Administrator
[4] => 0 )
[1] => Array ( [0] => 2
[1] => jodel_ross
[2] => 2cdaeb5df4cf941d9c5650591cba1fdc
[3] => Jodel Ross, Jr.
[4] => 1 ) )
Please help, I need to understand why and I have search the web for answers and have not found any.
Thanks.
Development environment:
Windows 7 x64
PHP 5.3.6
Mysql 5.5
Apache 2.0.64
Zend Framework 1.11
There is still an open error with Zend Framework 1.x, PHP 5.3.x and setFetchMode() and that's the reason why it doesn't work as expected.
see http://framework.zend.com/issues/browse/ZF-10866 and http://framework.zend.com/issues/browse/ZF-3470
Please vote for closing this error or submit a patch.