ObjectDB.search ne remontent pas d'enregistrement

Support
1

Request description

Bonjour,
je tente de parcourir tous les enregistrements d’un objet en utilisant la méthode search de ObjectDB pour y effectuer un validateAndSave() de BusinessObjectTool.(Reprise de données)

Quand je teste, la taille de la liste est toujours 0 alors que object.getCount() me retourne le nombre attendu.

Je me suis basé sur la doc. Je me demande si mon implémentation contient une erreur qui m’échappe ?

ObjectDB object = g.getTmpObject(item);
synchronized (object.getLock()) {
	object.resetFilters();
	List<String[]> recordList = object.search(false);
	AppLog.info("recordList.size total records = "+recordList.size(), g);
	AppLog.info("getCount total records = "+ object.getCount(), g);
	}

Technical information

Instance /health 
[Platform]
Status=OK
Version=5.3.45
BuiltOn=2024-08-18 13:52
Git=5.3/afbdc085b6d18cb2051762fd69ca60a5a234e042
Encoding=UTF-8
EndpointIP=100.88.206.32
EndpointURL=http://bca-68521-app-5cf7bf84d4-7wtqz:8080
TimeZone=Europe/Paris
SystemDate=2024-10-04 15:02:16

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=https://bcsi-app.ext.gke2.dev.gcp.renault.com
ActiveSessions=2
TotalUsers=8733
EnabledUsers=1443
LastLoginDate=2024-10-04 15:00:00

[Server]
ServerInfo=Apache Tomcat/9.0.93
ServerType=WEB
ServerActiveSessions=2
ServerSessionTimeout=30
CronStarted=true

[OS]
Name=Linux
Architecture=amd64
Version=6.1.90+
DockerImageName=almalinux9
SystemEncoding=UTF-8

[JavaVM]
Version=17.0.12
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.12+7
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02
HeapFree=435825
HeapSize=1077248
HeapMaxSize=1581056
TotalFreeSize=939633

[Cache]
ObjectCache=316
ObjectCacheMax=10000
ObjectCacheRatio=3
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Database]
Vendor=2
VendorName=mysql
ProductName=MySQL
ProductVersion=5.7.44-google-log
DriverName=MySQL Connector/J
DriverVersion=mysql-connector-j-9.0.0 (Revision: e0e8e3461e5257ba4aa19e6b3614a2685b298947)
DBDate=2024-10-04 13:02:16
DBDateOffset=-7200
DBPatchLevel=5;P03;a4067bb64c54435ec5a9b948a3aa16b9;45
UsingBLOBs=true

[Healthcheck]
Date=2024-10-04 15:02:16
ElapsedTime=24
Simplicité logs 
Event: getCount total records = 493
Event :recordList.size total records = 0
2

Votre code semble Ok. Peut être avez vous du code sur l’objet en question qui filtre des choses au search (par positionnement conditionnel d’une search spec ou au niveau du postSearch).

Test fait en reprenant votre code sur une v5 à jour sur la demo:

image
image2284×974 137 KB

Testez sur un autre objet et/ou sur celui-ci en inhibant le code de celui-ci

3

Merci pour ta réponse.
En fait il manquait un point qui est (maintenant je sais ) crucial à mon post, c’est l’emplacement de code, je pense qu’il était “trop tôt” dans les hooks du PlatformHooks. J’ai mis le même code dans le postLoadHome et ca fonctionne comme attendu.
Mon but est d’appliquer un traitement aux records de plusieurs objets qui contiennent un certain attribut, c’est pour ca que j’ai ciblé un PlatformHook pour ce besoin.
Merci du support et bon WE :smiley:

4

Juste pour comprendre, “trop tôt” ça veut dire dans quel platform hook ?

5

Je l’avais initialement positionné dans le preLoadGrant() car j’tétais (trop) focus sur le fait de faire le traitement selon les droits du user ciblé.

6

Bonjour,

Il faudrait revoir votre besoin de parcourir une table à l’ouverture de session pour mise à jour en masse ? Les Platform hooks doivent rester rapides pour que la session s’ouvre rapidement.

Si vous avez des traitements plus lourds sur les données (comme une reprise de données), il serait judicieux de les déporter dans un tache cron (automatiquement la nuit) ou via une action asynchrone lancée ponctuellement (par l’utilisateur ou un admin).

7

Bonjour François, en effet, j’ai choisi l’option de l’action quand j’ai vu le nombre d’enregistrements. Merci pour les conseils.

8

Je me permets de continuer dans ce topic car c’est lié au .search(),
ce bout de code issue de cette partie de la doc :

int maxRowsPerPage = 50;
object.search(true, maxRowsPerPage, (rows, pageNum) -> {
	for (String[] row : rows) {
		o.setValues(row, true);
		// ...
	}
});

me donne ce type d’erreur à la compilation:

Simplicité logs 
error: incompatible types: incompatible parameter types in lambda expression
				object.search(true, maxRowsPerPage, (rows, pageNum) -> {
				                                    ^
9

Effectivement en 5.3, la méthode lambda ne prend pas de pageNum en second paramètre.
Ca a été ajouté en V6 pour savoir calculer un row index global =
maxRowsPerPage * pageNum + rows index

On va préciser la documentation pour la 5.3 :

int maxRowsPerPage = 50;
object.search(true, maxRowsPerPage, (rows) -> {
	for (String[] row : rows) {
		o.setValues(row, true);
		// ...
	}
});

https://docs.simplicite.io/lesson/docs/core/basic-code-examples#java-7

1 Like
10

Pour conclure ce ticket, on va ajouter en 6.1.11 une compatibilité ascendante de la syntaxe V5 en V6 pour les appels de search et searchExport avec des lambdas sans second paramètre pageNum.

Ca évitera cette erreur de compilation quand vous passerez en V6.

1 Like
11

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.