Profildokument und Cache Problem

[jmanuel]

Hallo,

ich habe das folgende Problem. Über ein Profildokument werden Benutzereinstellungen gespeichert. Diese werden während des Benutzes mit meiner Applikation immer wieder abgefragt, aber das Problem ist, das Notes die Daten des Profildokuments im Cache behällt. Aus diesem Grund bekomme ich immer alte Werte als Rückgabewert. Kennt ihr da eine Lösung ?

jmanuel

[MartinG]

Bitte Forumssuche verwenden...

[Axel]

Hi,

wie Martin schon geschrieben hat, hatten wir das hier schon enige Male. Mit der Forumssuche solltest du einiges an Informationen finden.

Ausserdem kannst du auch mal hier schauen: Klasse für UserProfile


Axel

[jmanuel]

Hallo,

danke für eure Antworten. Ich habe die Klassen runtergeladen und die Demo-DB ausprobiert. Es sieht sehr vielversprechend aus, obwohl ich im Moment noch nicht weiss, wass die Klasse mit LScript alles so viel anders macht als es normal mit LScript zu programmieren. Wie gesagt, ich nehme das ganze mal unter die Lupe, und poste dann meine Ergebnisse.

jmanuel

[jmanuel]

Hallo nochmal,

ok, die Klassen simulieren also ein Profildokument, es ist kein Profildokument an sich, sondern ein normales Notes Dokument. Leider bin ich jetzt enttäuscht. 

[Thomas Schulte]

ok, die Klassen simulieren also ein Profildokument, es ist kein Profildokument an sich, sondern ein normales Notes Dokument. Leider bin ich jetzt enttäuscht.

Ach nee, ach was. Du bist also enttäuscht. Ja und was sagt uns das.

Nochmal, langsam und zum Mitschreiben. Profildokumente werden in Notes in den Cache geladen und dort auch solange gehalten bis der Benutzer seine Sitzung beendet. Ende Gelände, dieses Verhalten ist so seit es Profildokumente gibt. Da kann man jetzt drüber schimpfen, sich die Fingernägel abknabbern, das ist einfach so.

Die Klasse die Axel dir gezeigt hat ist eine Lösung die das Verhalten von Profildokumenten mit normalen Dokumenten simuliert. Nicht mehr und nicht weniger. Also kein Grund enttäuscht zu sein.

Thomas

[Axel]

Hallo nochmal,

ok, die Klassen simulieren also ein Profildokument, es ist kein Profildokument an sich, sondern ein normales Notes Dokument. Leider bin ich jetzt enttäuscht. 

Hi,

wieso bist du den enttäuscht? Was hast du denn erwartet?

Du hattest Probleme mit dem Cachig von Profildokumenten und diese Klasse stellt die normale Notesdokumente zur Verfügung, die zumindest von Script aus zu handeln sind wie Profildokumente. Darüber hinaus haben sie den Vorteil, dass sie nicht gecacht werden. D.h. die Werte die du in die Felder reinschreibst bekommst du, auch ohne die DB neu zu starten, wieder raus. Natürlich sind es keine richtigen Profildokumente, aber 95% der Einsatzgebiete von Profildokumenten kannst du mit der Klasse abdecken.

Und wenn dir was fehlt, kannst du die Klasse ja an deine Bedürfnisse anpassen bzw. erweitern. Den Code kannst du frei verwenden. Ich verlange keine Lizensgebühren.

Also was willst du mehr.


Axel

[jmanuel]

Hi nochmal,

sicherlich habt ihr recht. Ich hatte nur gehofft dass sich das Problem irgendwie lösen lässt durch irgendeinen Trick. Es gibt ja, wie wir mittlerweise wissen,  hunderttausende von workarounds.  Und wieso nicht eins für dieses Problem. Klar, die Klassen sind natürlich auch eine gute Alternative. Bei meinen Fall muss ich Profildokumente benutzen. Es ist mir vorgeschrieben. Nun überlege ich die Werte zu splitten.

grüsse,
jmanuel

[koehlerbv]

Bei meinen Fall muss ich Profildokumente benutzen. Es ist mir vorgeschrieben. Nun überlege ich die Werte zu splitten.

Der das vorschreibt, missverkennt aber vollkommen, wozu ProfileDocs da sind: Werte schnellstmöglich zur Verfügung haben. Dafür werden sie im Cache gehalten (was aber nur von Bedeutung sein sollte, wenn mehr als ein Benutzer darauf zugreift !).

Auf ProfileDocs kann man andererseits auch zugreifen wie auf vollkommen normale Notes-Dokumente, aber das würde dann ja Sinn und Zweck der ProfileDocs ad absurdum führen.

Kopfschüttelnd,
Bernhard

[jmanuel]

Hi,

ja das stimmt. Die Vorgabe des Profil wird mit dem Grund begründet, dass normale Dokumente gelöscht werden könnten, bei Replikation z.B. , der von Agenten, die Dokumente löschen, die älter sind als x. oder so. Klar kann man dass alles durch korrekte anwendung verhindern,  aber das vertrauen ist dann wiederrum nicht gegeben.

jmanuel

[koehlerbv]

Oh Mann - die Vorgabe steht ganz, ganz kurz vor der Grenze "Schwachsinn". Wenn die "richtige" Applikation 'rankommt, sind auch die ProfileDocs älter als "xxx days" dran.
Manuel, die Sache stinkt. Und zwar gewaltig.

Bernhard

PS: Nochmal direkt die Frage - sind das ProfileDocs, die jeweils nur einem User zur Verfügung stehen, oder sind die ProfileDocs userbezogen ?

PPS: Aber bei der "hochintelligenten" Anforderung ist das vielleicht auch wurscht.

[Axel]

Hi,

wenn du die Klassen verwendest, kannst du die Ansichten so verstecken, das der normale User da nicht dran kommt. Dann sieht es auch seine "Profildokumente" nicht und kann sie somit auch nicht löschen.


Axel

[jmanuel]

wenn du die Klassen verwendest, kannst du die Ansichten so verstecken, das der normale User da nicht dran kommt

Hi,

ja das werde ich wohl tun müssen. Nochmal zu den Profildokument, und zu Bernhard; es sind alles personenbezogene Userdokumente. Die Benutzer speichern auf diese Dokumente applikaitonsbezogene Daten, also solche, die ständig während des Benutzens aktuell sind. Wir sind dann wohl einer Meinung, das Profildokumente hierfür nichts taugen.

grüssse,
jmanuel