Re: Custom EOQualifier

2024-08-30 Thread OCsite via Webobjects-dev
André,

someone might give a much better and more straightforward answer, but myself, I 
would just check (and more or less imitate) how custom qualifiers are written 
in Wonder, whose sources are available publicly 
.

All the best,
OC

> On 30. 8. 2024, at 15:06, André Rothe via Webobjects-dev 
>  wrote:
> 
> Hi,
> 
> I need a custom EOQualifier, which executes for Strings in an Oracle database
> 
> WHERE UPPER(table.aStr) = UPPER(bStr)
> 
> (compare both Strings in uppercases). A QualifierOperatorCaseInsensitiveLike 
> will not work, because the Strings could contain "*", but these should not 
> act as wildcards.
> 
> How I can build such a class?
> 
> Greetings
> André
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: FB JDBC version?

2024-08-23 Thread OCsite via Webobjects-dev
Ramsey,

> On 23. 8. 2024, at 16:10, Ramsey Gurley  
> wrote:
> Check the startup logging in your app. I'm fairly sure a standard wonder app 
> dumps the entire classpath as part of the start of the startup logging.

It does; that's where I've found my classpath is definitely OK. Alas, the 
bloody Java ignores the classpath and happily loads the JDBC driver from 
java.ext.dirs, regardless the classpath path :(

Thanks,
OC

> 
> From: o...@ocs.cz 
> Sent: Friday, August 23, 2024 6:20 AM
> To: Ramsey Gurley ; WebObjects-Dev List 
> 
> Subject: Re: FB JDBC version?
>  
> Ramsey,
> 
> looks like you are again right. Meantime I've investigated, and it looks like
> - the bloody Java, despite having an explicit path to the proper driver on 
> classpath (I've checked in runtime logs, it's OK), still ignores it and loads 
> another driver from java.ext.dirs;
> - where, I believe, a FrontBase driver should never be anyway, but some 
> proactive admin seems to have put the old version to. Ick!
> 
> Is there a decent way for a given JAR to log out a path from which it has 
> been really loaded? I've tried to search Net, but did not found any. There 
> are ways to find a path for a known class (but I do not know which classes 
> there are in the FrontBase driver; and if I find a class they use now, it 
> might fail in future if they change the names), and even those, based on a 
> getProtectionDomain which might throw, are a bit complex to my liking...
> 
> Thanks a lot!
> OC
> 
>> On 22. 8. 2024, at 22:51, Ramsey Gurley > <mailto:ramsey.gur...@practicemojo.com>> wrote:
>> 
>> Are you sure you don't have more than one jdbc jar floating around in your 
>> application build path? With ant, I forget how it determines which jar wins. 
>> With maven, you can just open the pom.xml in eclipse and check in the 
>> Dependency Hierarchy tab.
>> From: OCsite via Webobjects-dev > <mailto:webobjects-dev@lists.apple.com>>
>> Sent: Thursday, August 22, 2024 2:54 PM
>> To: WebObjects-Dev List > <mailto:webobjects-dev@lists.apple.com>>
>> Subject: FB JDBC version?
>>  
>> Hi there,
>> 
>> how does one properly determine the current FB JDBC driver version?
>> 
>> Lately we were not sure whether all our installations contain the newest 
>> release, and thus I've added a code to log out the version. The code I've 
>> found — is there another, better, and more reliable variant? — looks like 
>> this:
>> 
>> ===
>> def eoa=EOAdaptor.adaptorWithModel(model)
>> def pin=eoa.plugIn()
>> logln "using driver $eoa.plugInName ${pin.jdbcInfo['DRIVER_VER']}"
>> ===
>> 
>> The problem is, this code gives me different results (sometimes 2.5.10, 
>> sometimes 2.5.9) for the very same frontbasejdbc.jar (which should really be 
>> 2.5.20 — 240643 bytes, md5 72266d135712d26c60bc5cc1e1dc7c94). What do I 
>> overlook?
>> 
>> Thanks,
>> OC
>> Confidentiality Notice: This email, including all attachments and replies 
>> thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. 
>> Sections 2510-2521 and are legally privileged. This information is 
>> confidential, and intended only for the use of the individuals or entities 
>> named above. If you are not the intended recipient, you are hereby notified 
>> that any disclosure, copying, distribution or the taking of any action in 
>> reliance on the contents of this transmitted information is strictly 
>> prohibited. Please notify us if you have received this transmission in 
>> error. Thank you.
> 
> Confidentiality Notice: This email, including all attachments and replies 
> thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. 
> Sections 2510-2521 and are legally privileged. This information is 
> confidential, and intended only for the use of the individuals or entities 
> named above. If you are not the intended recipient, you are hereby notified 
> that any disclosure, copying, distribution or the taking of any action in 
> reliance on the contents of this transmitted information is strictly 
> prohibited. Please notify us if you have received this transmission in error. 
> Thank you.

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


FB JDBC version?

2024-08-22 Thread OCsite via Webobjects-dev
Hi there,

how does one properly determine the current FB JDBC driver version?

Lately we were not sure whether all our installations contain the newest 
release, and thus I've added a code to log out the version. The code I've found 
— is there another, better, and more reliable variant? — looks like this:

===
def eoa=EOAdaptor.adaptorWithModel(model)
def pin=eoa.plugIn()
logln "using driver $eoa.plugInName ${pin.jdbcInfo['DRIVER_VER']}"
===

The problem is, this code gives me different results (sometimes 2.5.10, 
sometimes 2.5.9) for the very same frontbasejdbc.jar (which should really be 
2.5.20 — 240643 bytes, md5 72266d135712d26c60bc5cc1e1dc7c94). What do I 
overlook?

Thanks,
OC ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: overlapping R/Rs in same session

2024-08-21 Thread OCsite via Webobjects-dev
Aaron,

> On 21. 8. 2024, at 1:16, Aaron Rosenzweig  wrote:
> Sounds like maybe your session is in the URL? 

Nope, we store them in cookies.

> What if you put the session in a cookie? Then it’s not possible to have 
> multiple tabs in the same browser. The last tab wins. 

Alas, that's not how the browser works. Pretty often, e.g., if one opens a link 
by shift-cmd-click in a new tab, and in other cases too, more tabs/windows 
simply share the same wosid cookie, i.e., the same session.

Myself I use Safari exclusively, but based on 
https://stackoverflow.com/questions/49687204/same-browser-but-different-windows-do-they-share-cookies
 it seems it is a customary behaviour in other browsers, too.

Thanks,
OC

> 
>> On Aug 19, 2024, at 9:25 AM, ocs--- via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> Hi there,
>> 
>> looks like the main cause of those overlapping R/Rs which we ar clashing 
>> with lately is that some users just open their session in more windows or 
>> tabs, and work concurrently in those. Sigh.
>> 
>> It's self-evident why it is a pretty bad idea from the technical POV, but I 
>> am afraid we can't explain it to plain users. Worse, if we found a way to 
>> prevent that (offhand, I am not sure whether it is technically possible, but 
>> even if so), I am afraid the users would complain that they simply insist on 
>> this terrible approach.
>> 
>> Now though they complain some operations are “inexplicably” slow: “I 
>> understand that operation A which I've launched in one of my windows is 
>> complicated and thus takes many seconds, that's OK. But at the same moment 
>> I've launched an operation B in another of my windows; operation B is 
>> trivial and should be lightning fast, but it took an eternity! Fix your 
>> broken application!“
>> 
>> Well you twit, op B took an eternity since it first waited many seconds 
>> until the slow op A you yourself launched in the same session finished; 
>> after that, A took about 100 ms of its own time. But this kind of 
>> explanation would not do with plain users at all :(
>> 
>> Could anybody see any practical solution?
>> 
>> Note please that making _all_ R/R lightning fast is practically impossible 
>> (we would have to refactor too heavily, not an option in a near future). 
>> Besides I am afraid even if we somehow succeeded to make all R/R reliably 
>> belong a second or so, they would still launch ten second-long operations in 
>> ten windows plus one 100 ms in another, and then complain that the last one 
>> took seconds too :(
>> 
>> At this moment about the only solution very ugly work-around I can think of 
>> would be to choose a couple of the trivial operations whose speed the users 
>> consider most important, and re-write them without session (they would still 
>> need to work with the session ID, but important things like the current user 
>> etc. would have to be cached in the application in some kind of static map 
>> without using the Session instance at all). Sigh. Darn complex, but still 
>> worlds easier than attempting to make _all_ R/Rs 100ms-or-less...
>> 
>> Any better idea?
>> 
>> Thanks and all the best,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>> )
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
>> 
>> This email sent to aa...@chatnbike.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Solved: awake-time long lags

2024-08-13 Thread OCsite via Webobjects-dev
D'oh!

Further analysis proved that those R/Rs which sport a long lag awake-time are 
overlapping R/Rs of the same session.

Since the default EC, far as I know, gets locked immediately before session 
awake (and unlocked just after session sleep), the mystery of long lags is no 
mystery anymore (and since it is pre-awake, not in-awake, the profiler revealed 
no awake method took long). Sigh.

Now I wonder how to teach the users that if a R/R happens to be sorta slow, it 
definitely won't help to click at all the other links on the current page

All the best,
OC

> On 2. 8. 2024, at 2:32, ocs--- via Webobjects-dev 
>  wrote:
> 
> Hi there,
> 
> we are encountering another weird problem: a (very) long lag awake-time.
> 
> We happen to log the application-level awake and some of the component-level 
> awakes. Normally, the latter happen just a couple milliseconds from the 
> former. Nevertheless _sometimes_ when the load gets higher and more R/R loops 
> run concurrently, this lag grows up to a complete nonsense — tens or, in the 
> worst cases, hundreds of seconds (between Application.awake and some 
> Component.awake).
> 
> The most obvious answer that either the session-level awake or some of the 
> non-logged component-level awakes might take an eternity upon a higher load 
> is still an open possibility, but quite improbable one: we have profiled our 
> application when the problem did happen with a smaller load, a couple of 
> times the lag grew up to about 5-7 s, and still none of the awake methods 
> ever took more than 40 ms.
> 
> Has perhaps anyone here encountered a similar problem and might suggest a 
> solution or at least a reasonable way to find the culprit?
> 
> Thanks and all the best,
> OC
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


find EO's PK without side-effects?

2024-08-05 Thread OCsite via Webobjects-dev
Hi there,

can I somehow get a PK of an EO without uglies like locking its EC and so forth?

Naïvely I thought that this specific information should be readily available 
somewhere simply by reading from memory without any other ado (even for a 
fault, not speaking of an in-memory EO), but self-evidently I was wrong; lately 
I was bitten in tender parts by rawPrimaryKey auto-locking EC.

Thanks,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: awake-time long lags

2024-08-01 Thread OCsite via Webobjects-dev
Aaron,

> On 2. 8. 2024, at 2:33, Aaron Rosenzweig  wrote:
> How is your RAM headspace? Is it possible you are running out of runway? 
> Maybe it’s doing lots of garbage collection.

Alas, not probably.

I forgot to mention that at the very same time when _some_ R/Rs sport the 
terrible tens- or even hundreds-second lag, most _other_ ones run concurrently 
with that and work quite normally (their component-level logged-out awake comes 
just a couple of millis after the app-level one). Far as I understand Java, it 
suspends all threads while GCing, so all R/Rs would be affected the same way, 
would they not?

Besides we happen to log the memory state, too, and most time (especially when 
the worst lag happened) we are well below 20 % of the max available Java memory 
(-Xmx), which itself is well below the physical RAM. Far as I can say, there 
was no other memory-consuming task at the same moment (but for FrontBase, I 
understand there's essentially nothing other  of importance running on that 
machine than the WO app).

Thanks a lot!
OC

> 
>> On Aug 1, 2024, at 8:32 PM, ocs--- via Webobjects-dev 
>>  wrote:
>> 
>> Hi there,
>> 
>> we are encountering another weird problem: a (very) long lag awake-time.
>> 
>> We happen to log the application-level awake and some of the component-level 
>> awakes. Normally, the latter happen just a couple milliseconds from the 
>> former. Nevertheless _sometimes_ when the load gets higher and more R/R 
>> loops run concurrently, this lag grows up to a complete nonsense — tens or, 
>> in the worst cases, hundreds of seconds (between Application.awake and some 
>> Component.awake).
>> 
>> The most obvious answer that either the session-level awake or some of the 
>> non-logged component-level awakes might take an eternity upon a higher load 
>> is still an open possibility, but quite improbable one: we have profiled our 
>> application when the problem did happen with a smaller load, a couple of 
>> times the lag grew up to about 5-7 s, and still none of the awake methods 
>> ever took more than 40 ms.
>> 
>> Has perhaps anyone here encountered a similar problem and might suggest a 
>> solution or at least a reasonable way to find the culprit?
>> 
>> Thanks and all the best,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
>> 
>> This email sent to aa...@chatnbike.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


FrontBase speed, feels weird.

2024-07-15 Thread OCsite via Webobjects-dev
Hi there,

for years and years, we happily use FrontBase. Lately though we are bumping 
into somewhat weird behaviour: we observe inexplicably long fetches, even with 
tables which are not extremely big, no joins, trivial conditions. What's even 
more intriguing is that in sql92, it was much faster. Even so, the problem was 
at the FB (not application) side, for an index did help tremendously. Does not 
make really sense to me, and I wonder whether there might be some weird problem 
in the FB itself, which might raise its head soon and bite us hard.

- the table contains about 16 000 rows, that's not too many;
- the fetch condition is trivial, just WHERE SOME_BOOLEAN_COLUMN = false;
- the number of found rows is only 13 currently (and never exceeded 100).

These fetches took seconds — usually about 1200 ms, not once below 1000, 
occasionally almost 3000 ms.

When I've tried the very same fetch in sql92, it was instantaneous, which feels 
pretty weird too and lead me to a suspicion that the problem is at the 
application side.

Nevertheless it was not: I just have added an index for the column, and the 
fetches are ways quicker now (usually below 30 ms).

What intrigues me and the reason I write this mail, it does not seem to me 
reasonable that a plain fetch from a table of ~16K rows which yields 
(considerably) less than 100 result rows, without any join and with a 
completely trivial condition, could (without an index) take that long. Does it 
make any sense to you, who understand SQL/FB better than me? Is that normal? 
There are other fetches from the same table, with considerably more complex 
conditions, taking at worst a couple tenths of second; that seems normal to me.

Thanks and all the best,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: [POSSIBLY SOLVED]: Cannot obtain globalId for an object which is registered in an other than the databaseContext's active editingContext

2024-06-09 Thread OCsite via Webobjects-dev
Just a quick followup: I've tested further, and alas, looks like the very same 
problem may happen regardless the fetchTimestamp due to inverse flattened M:N 
relationships.

Test case same as below, just without 1/4, but with a flattened M:N two-side 
relationship; culprit in (vii) very slightly different — the original 
relationship gets filled from the snapshot without any problem, but the inverse 
may (quite probably) need to be fetched, with precisely the same outcome. Sigh.

> On 9. 6. 2024, at 2:46, ocs--- via Webobjects-dev 
>  wrote:
> 
> Hi there again,
> 
> I was eventually able to repeat the problem and it sort of stinks by a bug in 
> EOF (or I am doing something wrong, of course, as so often :)) My test code 
> is just a wee bit at the convoluted side, based on my own model and besides 
> written in Groovy, thus there's no point in quoting it; but the gist is this:
> 
> 1. create an EC1, assign it a fetchTimestamp in future (something like 
> System.currentTimeMillis()+1500 should suffice)
> 2. lock EC1
> 3. fetch into EC1 an object with a :N relationship and change that 
> relationship, not saving the changes
> 4. wait until the fetchTimestamp expires
> 5. in a separate thread with its own EC2 (locked) change the same 
> relationship of the same object (localInstanceIn(EC2) of course)
> 6. save the changes in EC2
> 7. back in the original thread, wait until the thread with steps 5 and 6 
> ends. Then unlock EC1
> 8. finally, in an unrelated EC3 insert some unrelated new object and 
> saveChanges...
> 
> ... and at least at my side, I get “Cannot obtain globalId for an object 
> which is registered in an other than the databaseContext's active 
> editingContext“ exception all right!
> 
> I believe the steps above are completely valid and should not cause problems, 
> or do I overlook something here?
> 
> I might be wrong, it is a bit at the complex side, but I think this is what 
> happens under the hood:
> (i) EC3 saveChanges of step 8 just calls 
> EOObjectStoreCoordinator.saveChangesInEditingContext ...
> (ii) which first makes sure there's a proper source (happens to be 
> EODatabaseContext) for each inserted object in its _sources; this 
> EODatabaseContext happens to be the only shared EODatabaseContext a simple 
> application like this one uses (no more OSCs, no concurrent DB access)
> (iii) each _source gets _willPrepareForSave and then each _source gets 
> prepareForSaveWithCoordinator — and this sets its _editingContext to EC3!
> (iv) furthermore each _source gets recordChangesInEditingContext, 
> performChanges, and eventually commitChanges
> (v) inside of commitChanges, EODatabaseContext finds that some changes really 
> happened and posts EOGlobalIDChangedNotification
> (vi) EC1, which up to this moment was dormant, observes this notification and 
> through _globalIDChanged, _sendOrEnqueueNotification, yadda yadda, eventually 
> gets to merge the change into its own object
> (vii) which change includes checking the current relationship value. Since 
> the fetchTimestamp is already in the past, this involves re-fetching the 
> relationship in EC1 ...
> (viii) ... which goes through the one and only shared EODatabaseContext we 
> have. That EODatabaseContext though still has its _editingContext set to EC3 
> from the step (iii))!
> 
> Hilarity ensues, the “Cannot obtain globalId for an object which is 
> registered in an other...” exception gets thrown (if this did not happen, the 
> EODatabaseContext's _editingContext would get nulled at the very end of 
> commitChanges, too late for us).
> 
> Do I overlook something of importance? Seems me not to; I guess anyone can 
> repeat the test code 1-8 outlined above (just beware logs — they might fire 
> the fault prematurely; also I've found essentially each localInstanceIn locks 
> ECs and thus disrupts the normal processing — best to prepare all the ECs and 
> all their local instances at the very start, around the step 1).
> 
> What would be the best fix/work-around? I can't see any simple one; and I 
> would rather not override and re-implement the complete and rather 
> non-trivial commitChanges method.
> 
> Thanks and all the best,
> OC
> 
>> On 8. 6. 2024, at 4:38, ocs--- via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> Hi there,
>> 
>> again in about 2 years the $subject did happen:
>> 
>> “Cannot obtain globalId for an object which is registered in an other than 
>> the databaseContext's active editingContext, object: 
>> [USER#1000175@EC:34ea315d/OSC:77b7ffa4], databaseContext: 
>> com.webobjects.eoaccess.EODatabaseContext@512d92b, object's editingContext: 
>> EC:34ea315d/OSC:77b7ffa4, databaseContext's active editingContext: 
>> EC:7de5b11a/OSC:77b7ffa4“
>> 
>> (ECs are my subclasses which log out the appropriate OSC, too; did that when 
>> I've hunted for bugs in multi-OSC environment. Unimportant here, in this 
>> case all OSCs are same.)
>> 
>> Again, as before, the cause were the changes pr

re/store context somehow?

2024-05-16 Thread OCsite via Webobjects-dev
Hi there,

my client made a somewhat weird request: wants me to store “the last context 
the user worked in” in his session, and restore it when the user comes to the 
application through a specific Direct Action (and the session still lives).

In other words, suppose the user works in the app for awhile, and then closes 
his browser, remembering just the session ID, nothing else.

Next thing he does, he opens 
.../OurApp.woa/wa/restorePrevious?wosid=prevSessionID — and wow, he finds the 
browser window in precisely the same state it was when he closed the browser 
some time ago. (Far as possible of course, let's assume for simplicity the 
internal app/session/DB state did not change meantime.)

I guess most probably I need to save context().clone() into session each time 
in Session.sleep(), that's not difficult. But then in my 
DirectAction.restorePreviousAction I need to resurrect the saved context 
somehow, but I can't find a way to do that. Does anybody know how to?

Thanks!
OC ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


.wo parser/validator?

2024-05-03 Thread OCsite via Webobjects-dev
Hi,

is there a commandline tool which would parse and validate a .wo, so that I 
could include it into my toolchain and get warnings and errors for malformed 
html templates build-time, instead of run-time when the appropriate page is 
opened?

Thanks!
OC
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


enumerating sessions?

2024-04-26 Thread OCsite via Webobjects-dev
Hi there,

is there a way to enumerate sessions which are alive inside of a 
WO/ERXApplication?

I guess I can create such a list myself, adding new ones in session.awake, 
keeping it weak not to prevent old sessions to be destroyed (or perhaps storing 
just session IDs), yadda yadda, but it would be much easier and less 
error-prone just to use a WO/nder service, if there's one.

The purpose is that we need to allow an app administrator to list all the 
normal users which are currently logged in, and be able to force-logout 
selected ones.

Thanks!
OC
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: loooong saveChanges prep-stage

2024-02-01 Thread OCsite via Webobjects-dev
Thanks again!

Though I do not really think the database would be the culprit. Does actually 
EOF do anything with the DB when saving changes before 
DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations is called? 
I might be wrong as so often, but I don't think so; I believe it contacts the 
DB for the first time only after that.

Thanks and all the best,
OC

> On 1. 2. 2024, at 6:12, Ramsey Gurley  wrote:
> 
> Are you hosting your database? If so, don't rule out a problem outside your 
> application and in your database. It could be low memory. If you can't fit 
> all the tables/indexes into memory, you fall off a performance cliff by going 
> to disk. It could also be an antivirus scanner that kicked off on your DB's 
> data directory. Once it starts scanning and locking files, it can ruin 
> performance. If you can catch it during these slow periods, ssh into the box 
> and check with top and iostat. Look for something on the machine tying up 
> resources. It could be a poorly tuned database too, your box has plenty of 
> memory, but your database isn't configured correctly to use it. For example, 
> if you're using Postgres:
> https://pgtune.leopard.in.ua/
> 
> It could even be below your database config and in your OS config. On linux, 
> it's highly dependent on which file system you are using (ext4, btrfs, xfs, 
> etc), but maybe you have insufficent read-ahead, or some other filesystem 
> setting. Even if you're not using Postgres, you should probably get a copy of 
> Postgresql High Performance and read the first few chapters which covers 
> hardware tuning below the database.
> 
> It could also be your database is busy reindexing or freeing up table space. 
> On postgres, vacuuming and reindexing can lock tables until the job is done. 
> This can take several minutes or more depending on the size of your table. It 
> could be the autovacuum doing it. If you're not vacuuming/reindexing, that 
> can hurt your performance too, since indexes will grow to exceed your 
> available memory and drop you off the performance cliff. You can do the 
> maintenance and get around the locking problems using something like 
> pg_repack.
> From: OCsite 
> Sent: Wednesday, January 31, 2024 7:59 PM
> To: OCsite via Webobjects-dev 
> Cc: Jérémy DE ROYER ; Ramsey Gurley 
> 
> Subject: Re: lng saveChanges prep-stage
>  
> You don't often get email from o...@ocs.cz. Learn why this is important 
> <https://aka.ms/LearnAboutSenderIdentification>   
> Thanks, guys!
> 
> I am pretty sure though the problem can't be a background process either 
> reading for a long time or saving for a long time, for I do use the 
> ERXAdaptorChannelDelegate.trace logs and through 
> DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations I log 
> each save — and there's nothing like that in the log in the vicinity of those 
> long saveChanges, alas. Thus the culprit must be something else.
> 
> Perhaps indeed something locks the OSC pretty often and for a long time, but 
> that something is neither a long SELECT which would log through 
> ERXAdaptorChannelDelegate.trace, nor another unrelated save, which would log 
> through DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations.
> 
> Besides, it does not really feel like OSC locks caused by another thread. 
> Meantime, I've rigged an awk script to compute how long each saveChanges 
> takes, and it looks like this:
> - for a long time, all is OK
> - when the save times begin to grow, they keep consistently long (e.g., about 
> 30 s each, or about 50 s each) for each save for awhile (a quarter or half an 
> hour), before things get back to normal
> 
> If another thread locked OSC, it would most probably mean some saveChanges 
> would be long, but some quick; it does not seem probable a background thread 
> would consistently keep OSC locked so that each saveChanges takes roughly the 
> same (long) time.
> 
> This rather feels by something at the beginning of saveChanges becomes slow. 
> This would most probably happen under the OSC lock, and given the way it 
> works, does not seem really plausible that it is simply waiting to acquire 
> the lock itself.
> 
> For the moment, I'm rather outta ideas :(
> 
> Thanks again and all the best,
> OC
> Confidentiality Notice: This email, including all attachments and replies 
> thereto, are covered by the Electronic Communications Privacy Act, 18 U.S.C. 
> Sections 2510-2521 and are legally privileged. This information is 
> confidential, and intended only for the use of the individuals or entities 
> named above. If you are not the intended recipient, you are hereby notified 
> that any disc

Re: loooong saveChanges prep-stage

2024-01-31 Thread OCsite via Webobjects-dev
Thanks, guys!

I am pretty sure though the problem can't be a background process either 
reading for a long time or saving for a long time, for I do use the 
ERXAdaptorChannelDelegate.trace logs and through 
DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations I log each 
save — and there's nothing like that in the log in the vicinity of those long 
saveChanges, alas. Thus the culprit must be something else.

Perhaps indeed something locks the OSC pretty often and for a long time, but 
that something is neither a long SELECT which would log through 
ERXAdaptorChannelDelegate.trace, nor another unrelated save, which would log 
through DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations.

Besides, it does not really feel like OSC locks caused by another thread. 
Meantime, I've rigged an awk script to compute how long each saveChanges takes, 
and it looks like this:
- for a long time, all is OK
- when the save times begin to grow, they keep consistently long (e.g., about 
30 s each, or about 50 s each) for each save for awhile (a quarter or half an 
hour), before things get back to normal

If another thread locked OSC, it would most probably mean some saveChanges 
would be long, but some quick; it does not seem probable a background thread 
would consistently keep OSC locked so that each saveChanges takes roughly the 
same (long) time.

This rather feels by something at the beginning of saveChanges becomes slow. 
This would most probably happen under the OSC lock, and given the way it works, 
does not seem really plausible that it is simply waiting to acquire the lock 
itself.

For the moment, I'm rather outta ideas :(

Thanks again and all the best,
OC ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


loooong saveChanges prep-stage

2024-01-30 Thread OCsite via Webobjects-dev
Hi guys,

I've got logs from one of our installations with a pretty weird problem.

We just happen to log immediately before ec.saveChanges() gets called; and we 
happen to have a 
DatabaseContextDelegate.databaseContextWillPerformAdaptorOperations, which logs 
out soon as it is called.

In this one log, the delay betw. those two logs — ie., the time saveChanges 
spends before the delegate method is called — repeatedly grows up to almost a 
minute (!) After some time the problem disappears and saving works normally; 
and then it occurs again. There's no other log around (most other threads wait 
on the OSC lock anyway), and with our app it so happens there's only one item 
in the adaptor op array to be inserted or updated.

Once or twice there even has been nothing to save at all (ie., no changes in 
the EC when saveChanges was called), but even so, saveChanges took almost a 
minute before it returned. Can't be 100 % sure, but most probably, it was the 
very same problem; it is highly probable thus it does not depend on the 
enterprise objects being saved, but on something else.

It never happened in any other installation of the same application, including 
my development one and our test one.

Have you ever bumped into something like that? Any idea what might be the 
culprit and how to hunt the bug?

Thanks a lot,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Might perhaps ERXEnterpriseObject.updateInverseRelationships fail?

2023-09-20 Thread OCsite via Webobjects-dev
H, I've just got a bugreport from the production, and looks like we have 
again bumped into the rare problem that (seemingly) sometimes 
ERXEnterpriseObject.updateInverseRelationships fails to update the :N 
relationship, as detailed below in my June e-mail.

Nobody happened to encounter a similar problem lately, or perhaps, even better, 
find a culprit and fix that?

Thanks a lot!
OC

> On 7. 6. 2023, at 11:12, OCsite via Webobjects-dev 
>  wrote:
> 
> Hi there,
> 
> pretty rarely, but alas repeatedly — something like, twice a year — our 
> clients observe a weird behaviour that
> - they add “a row to a table”, means an eo into a standard 1:N relationship;
> - immediately after that, they do not see the newly added row in the GUI, nor 
> do see it newly logged-in users, means their table.rows relationship does not 
> contain the new one;
> - in awhile, or if the app happens to be restarted, immediately after the new 
> launch, the problem disappears.
> 
> Not surprisingly, so far we haven't found any way to trigger the problem 
> intentionally :(
> 
> We have never observed similar problem with other relationships — which might 
> just as well mean it never happened, or that it does happen too, but just 
> never got noticed so far :)
> 
> I went repeatedly through the logs and so far found no reliable explanation, 
> but eventually it occurred to me if 
> ERXEnterpriseObject.updateInverseRelationships (which we use to keep all our 
> relationships in sync) happened to fail somehow, it would, I believe, cause 
> precisely the observed behaviour: the new object would be set up all right, 
> it would get its proper :1 relationship to the table (the appropriate FK 
> would be set and eventually saved to the DB all right), but the table's :N 
> inverse, for some weird reason, would not get updated to contain the new 
> object. New sessions (well all new ECs whichever way they are created) would 
> get the wrong (not-updated) relationship from table to rows from the to-many 
> snapshot, until the EC timestamp lag times out. When it does (or when the app 
> gets relaunched), the relationships gets re-fetched from the database, which 
> fixes the problem.
> 
> My primary question is, has anybody lately observed any problems with 
> ERXEnterpriseObject.updateInverseRelationships reliability?
> 
> Thanks!
> OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Might perhaps ERXEnterpriseObject.updateInverseRelationships fail?

2023-06-07 Thread OCsite via Webobjects-dev
Hi there,

pretty rarely, but alas repeatedly — something like, twice a year — our clients 
observe a weird behaviour that
- they add “a row to a table”, means an eo into a standard 1:N relationship;
- immediately after that, they do not see the newly added row in the GUI, nor 
do see it newly logged-in users, means their table.rows relationship does not 
contain the new one;
- in awhile, or if the app happens to be restarted, immediately after the new 
launch, the problem disappears.

Not surprisingly, so far we haven't found any way to trigger the problem 
intentionally :(

We have never observed similar problem with other relationships — which might 
just as well mean it never happened, or that it does happen too, but just never 
got noticed so far :)

I went repeatedly through the logs and so far found no reliable explanation, 
but eventually it occurred to me if 
ERXEnterpriseObject.updateInverseRelationships (which we use to keep all our 
relationships in sync) happened to fail somehow, it would, I believe, cause 
precisely the observed behaviour: the new object would be set up all right, it 
would get its proper :1 relationship to the table (the appropriate FK would be 
set and eventually saved to the DB all right), but the table's :N inverse, for 
some weird reason, would not get updated to contain the new object. New 
sessions (well all new ECs whichever way they are created) would get the wrong 
(not-updated) relationship from table to rows from the to-many snapshot, until 
the EC timestamp lag times out. When it does (or when the app gets relaunched), 
the relationships gets re-fetched from the database, which fixes the problem.

My primary question is, has anybody lately observed any problems with 
ERXEnterpriseObject.updateInverseRelationships reliability?

The other question is, I am considering to change my current straightforward 
row object code

void setTable(DBTable table) {
takeStoredValueForKey(table,'table') // setting the :1 relationship, 
trusting Wonder to sync the inverse
}

to this ugly contraption, which — or so I hope! — might catch the problem the 
next time it happens and attempt to fix it immediately:

void setTable(DBTable table) {
takeStoredValueForKey(table,'table')
if (!(this in table.records)) { // the inverse :N was not updated?!?
Log.warn "Something wrong with updateInverseRelationships!!!"
EOObjectStoreCoordinator osc=this.editingContext.rootObjectStore
EOEntity 
entity=EOModelGroup.modelGroupForObjectStoreCoordinator(osc).entityNamed(this.entityName)
EODatabaseContext 
dc=EODatabaseContext.registeredDatabaseContextForModel(entity.model(), osc)
dc.lock()
try { dc.database.forgetAllSnapshots() }
finally { dc.unlock() }
Log.warn "having re-fetched, now seems OK: "+(this in table.records)
}
}

Can you perhaps see a problem with that code, or would you suggest another 
approach? Am I right that database.forgetAllSnapshots() is safe in the sense 
that no data (including changes in ECs not yet saved) would be lost?

Thanks!
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: choosing the submit for Enter in a textfield?

2023-03-28 Thread OCsite via Webobjects-dev
René,

> On 28. 3. 2023, at 14:23, René Bock  wrote:
> I guess the only non JS solution would be to split the form in two different 
> forms.

Thanks, but since the layout is

[some form 1 items]
[complete form 2]
[other form 1 items]

I don't think I can do that. Perhaps if I could add the “form” attribute to the 
form 2 inputs it might work; but far as I know, with standard WO/nder inputs 
and submits that is not possible (or is it?), and although I could write my own 
ones, well, it's still easier to use the darned JS :)

Thanks and all the best,
OC

>> Am 26.03.2023 um 23:05 schrieb ocs--- via Webobjects-dev 
>> :
>> 
>> Hi there,
>> 
>> I've got a form (combined from more separate components) whose overall 
>> layout is
>> 
>>  
>> ... lots of inputs incl. a number of textfields ...
>> 
>> 
>> 
>> ... other inputs and textfields ...
>> 
>> 
>> 
>> I would need that an Enter in the "bar" textfield triggers "barAction"; an 
>> Enter in any other textfield triggers "fooAction".
>> 
>> Can this be done in a clean, preferably non-JS way?
>> 
>> I've found that I can put an invisible submit/fooAction at the place of [1], 
>> in which case _all_ Enters in _all_ textfields trigger "fooAction", but I 
>> haven't been able to find any nice way to ensure an Enter in the "bar" 
>> textfield triggers "barAction". With JS, I can do that, but it is really 
>> darn ugly (and besides it wouldn't work if the user switches off JS for 
>> security).
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: M:N-like table with a contents, updating the PK leads to problems

2022-10-11 Thread OCsite via Webobjects-dev
markus,

thanks!

> On 11. 10. 2022, at 11:55, mailinglists  wrote:
> Thou shall never ever change a primary key!

Yup, I suspected that it would be the culprit.

> Replace the compound PK with a “real” ID and be done. This is not such a big 
> thing to do. I've done this several times. You need a bit of SQL to “fix” 
> your database, but that is no rocket science.

I must admit SQL is not my force. I've tried in Frontbase Manager to
- add a new INT column c_uid to the table
- remove the primary key flag from both department_id and user_id
- add the flag to the new column
and I keep getting errors.

> This m:n join table is not a mere technical requirement anymore but now 
> represents business logic so it really really should have its own dedicated 
> primary key.

Well yes; on the other hand, when this happened, there was absolutely no 
intention to ever change the user (or department) relationship. Thus it was 
much easier to keep the PK as-was.

> At least that’s how I would do it.

I wonder whether it wouldn't be easier as Ramsey suggested to delete the object 
and insert a new one, which would be a copy of the old one but for the user_id 
value.

Actually, given that, I wonder whether it might be possible to
(a) just change the user_id value of the existing object;
(b) and somehow make EOF to think nothing was updated; instead that the old one 
was deleted and new one inserted.

For, far as the database contents goes, there would be no difference 
altogether. The difference is purely WO-side, in the way the changes are merged 
into snapshots and other ECs.

That would be, I suppose, far easiest approach — if, that is, (b) can be done 
reliably. Would that be possible somehow?

Thanks and all the best,
OC

>> On 11 Oct 2022, at 00:16, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> Hi there,
>> 
>> I've just bumped into a new problem. There's a table which, many years ago, 
>> was created as an invisible M:N intermediate table. Later, we needed to add 
>> some information to the relationship, so now we have a table, say, 
>> Connection, which has
>> - a number of normal attributes
>> - a compound PK (department_id, user_id) which contains two FKs into two 
>> other tables, say, User and Market (the remaining of the original M:N 
>> intermediate)
>> - two :1 relationships to those two tables (user and market).
>> 
>> Both User and Market tables model :N relationships connections (owning, 
>> PK-propagating), which long long ago replaced the original flattened M:N 
>> ones. Worked like a charm for years.
>> 
>> Now though, I've got a new requirement: I need to be able to change the user 
>> of a given Connection.
>> 
>> I've found that 
>> aConnection.addObjectToBothSidesOfRelationshipWithKey(newUser,'user') seems 
>> to work sort of properly — looks like all the relationships are properly 
>> updated and the key in the Connection table is changed in the database all 
>> right.
>> 
>> The catch is, sometimes (by far not always), a short time after the change, 
>> I start getting
>> 
>> No Connection found with globalID: > Y] >
>> 
>> with the original pre-change values of X and Y.
>> 
>> I can't be quite sure, but I think probably there's sometimes a :N 
>> User.connections snapshot which contains the  globalID of the original 
>> object. Since the user relationship change of its target actually changes 
>> the very PK of the object, the EOF synchronisation does not match the 
>> updated object (with a different PK => different globalID) with the original 
>> one and does not update the snapshot. Then, someone touches the 
>> relationship, gets the snapshot, EOF creates a fault with the original 
>> values, and when the fault fires, oops, there's nothing like that in the 
>> database.
>> 
>> Does anybody see how to fix the problem?
>> 
>> In principle I guess I could go programmatically through all the :N 
>> snapshots and try to find the old globalIDs and replace them by the new 
>> ones; but it would be sorta non-trivial and definitely dangerous...
>> 
>> Thanks,
>> OC
>> 
>> 
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/mailinglists%40kataputt.com
>>  
>> <https://lists.apple.com/mailman/options/webobjects-dev/mailinglists%40kataputt.com>
>> 
>> This email sent to mailingli...@kataputt.com
> 
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


M:N-like table with a contents, updating the PK leads to problems

2022-10-10 Thread OCsite via Webobjects-dev
Hi there,

I've just bumped into a new problem. There's a table which, many years ago, was 
created as an invisible M:N intermediate table. Later, we needed to add some 
information to the relationship, so now we have a table, say, Connection, which 
has
- a number of normal attributes
- a compound PK (department_id, user_id) which contains two FKs into two other 
tables, say, User and Market (the remaining of the original M:N intermediate)
- two :1 relationships to those two tables (user and market).

Both User and Market tables model :N relationships connections (owning, 
PK-propagating), which long long ago replaced the original flattened M:N ones. 
Worked like a charm for years.

Now though, I've got a new requirement: I need to be able to change the user of 
a given Connection.

I've found that 
aConnection.addObjectToBothSidesOfRelationshipWithKey(newUser,'user') seems to 
work sort of properly — looks like all the relationships are properly updated 
and the key in the Connection table is changed in the database all right.

The catch is, sometimes (by far not always), a short time after the change, I 
start getting

No Connection found with globalID: 

with the original pre-change values of X and Y.

I can't be quite sure, but I think probably there's sometimes a :N 
User.connections snapshot which contains the  globalID of the original object. 
Since the user relationship change of its target actually changes the very PK 
of the object, the EOF synchronisation does not match the updated object (with 
a different PK => different globalID) with the original one and does not update 
the snapshot. Then, someone touches the relationship, gets the snapshot, EOF 
creates a fault with the original values, and when the fault fires, oops, 
there's nothing like that in the database.

Does anybody see how to fix the problem?

In principle I guess I could go programmatically through all the :N snapshots 
and try to find the old globalIDs and replace them by the new ones; but it 
would be sorta non-trivial and definitely dangerous...

Thanks,
OC



 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: file download + refresh

2022-09-02 Thread OCsite via Webobjects-dev
Thanks! Alas, although I do use my own poor-man's Ajax-like code (which 
actually predates Ajax :)) in some pages, in this particular case it would be 
sorta overkill.

Having checked all the possibilities I've accepted (with a surprise) that such 
a trivial task is highly non-trivial :), and instead re-written the application 
so that the refresh is not needed anymore. That was easiest solution by far :)

Thanks again,
OC

> On 2. 9. 2022, at 9:29, Hugi Thordarson  wrote:
> 
> If you're using the Ajax framework, you can also do something like…
> 
> 
>   Number of downloads: 
> 
> 
> 
> Download
> 
> …and just increment numberOfDownloads on each download.
> 
> Note that AjaxPing submits lightweight requests at regular intervals (3000ms 
> by default, settable by the frequency binding) to check for changes to the 
> watched value, so it might not be suitable if you have a lot of these pages 
> open for a longer time.
> 
> Cheers,
> - hugi
> 
> 
>> On 1 Sep 2022, at 10:13, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> Hi there,
>> 
>> thanks for previous answers, the JS solution works like a charm. 
>> Nevertheless, I've bumped into another problem: along with downloading the 
>> file (returning appropriate WOResponse from my action method), I would need 
>> to refresh the page as well, to increment a visible download counter etc. Is 
>> there a known solution for that? I guess again some JS trick will be needed, 
>> and alas, JS is not my forte.
>> 
>> Thanks again,
>> OC
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is 
>> <https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is>
>> 
>> This email sent to h...@karlmenn.is
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


file download + refresh

2022-09-01 Thread OCsite via Webobjects-dev
Hi there,

thanks for previous answers, the JS solution works like a charm. Nevertheless, 
I've bumped into another problem: along with downloading the file (returning 
appropriate WOResponse from my action method), I would need to refresh the page 
as well, to increment a visible download counter etc. Is there a known solution 
for that? I guess again some JS trick will be needed, and alas, JS is not my 
forte.

Thanks again,
OC
 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: owns destination + deny prohibited?

2022-02-27 Thread OCsite via Webobjects-dev
Philippe,

> ... The fact that an EO is deleted when it's removed from the relationship is 
> technical consequence of a model. Don't use it because it's practical ...

Um, what other reason is there to use owning relationships? The documentation 
says

“If a source object owns its destination object, for example, as when an Agent 
object owns its Customer objects, then when something happens so that a 
destination object (Customer) is removed from the relationship, it is also 
removed from the data source. Ownership implies that an owned object cannot 
exist without its owner/”

(in three-odd different places, but always using essentially the same words), 
and if there's anything else in there, I can't find it. I might be completely 
wrong, but this suggests to me that a deletion of object removed from the 
relationship is the very (and also only) purpose of the ”owns” flag?

Thanks and all the best,
OC

> On 27 Feb 2022, at 14:46, Philippe Rabier  wrote:
> 
> Hi OC,
> 
> When an EO entity A owns an entity  B, consider A and B as a whole. B does 
> not exist separately. If you'd use a nosql document database, everything will 
> be in the same document. The best and known examples of usage are invoices or 
> quotes and their lines. 
> 
> What you want to do is to prevent deletion depending of other information 
> like the invoice status where a hypothetical VALID status would prevent the 
> deletion of the invoice. In that case and if you use Wonder, you could raise 
> an exception when the method willDelete is called. 
> 
> However, in your case, I have some doubts that a company owns departments 
> because maybe a department is linked to employees or budget or other stuffs … 
> a red flag is when you write that all departments must be deleted first 
> before the company. The fact that an EO is deleted when it's removed from the 
> relationship is technical consequence of a model. Don't use it because it's 
> practical in some case ( and in your case, it's not so practical ;-))
> 
> Philippe 
> 
> Sent from my iPhone
> 
> 
>> On 27 Feb 2022, at 12:45, OCsite via Webobjects-dev 
>>  wrote:
>> 
>> Hi there,
>> 
>> as I am checking all my relationships to make sure I did not another 
>> mistake, I've bumped into something strange.
>> 
>> It looks like EOF prohibits a combination of “owns destination” and the 
>> “deny” delete rule.
>> 
>> Can perhaps anybody explain the rationale behind that?
>> 
>> I must be overlooking something of importance, for it seems to me it is 
>> quite acceptable approach something like “a company owns all the 
>> departments. Whenever one is removed from the relationship, it should be 
>> deleted, no point for it existing separately. Still, I want to prevent 
>> deletion of a whole company which contains a non-zero number of departments; 
>> to prevent user errors, if somebody does want to delete a company, I want 
>> him to remove all its departments first”.
>> 
>> What am I missing?
>> 
>> Thanks,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/prabier%40icloud.com
>> 
>> This email sent to prab...@icloud.com

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


owns destination + deny prohibited?

2022-02-27 Thread OCsite via Webobjects-dev
Hi there,

as I am checking all my relationships to make sure I did not another mistake, 
I've bumped into something strange.

It looks like EOF prohibits a combination of “owns destination” and the “deny” 
delete rule.

Can perhaps anybody explain the rationale behind that?

I must be overlooking something of importance, for it seems to me it is quite 
acceptable approach something like “a company owns all the departments. 
Whenever one is removed from the relationship, it should be deleted, no point 
for it existing separately. Still, I want to prevent deletion of a whole 
company which contains a non-zero number of departments; to prevent user 
errors, if somebody does want to delete a company, I want him to remove all its 
departments first”.

What am I missing?

Thanks,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Wrong SQL when joining in an OR-part of the qualifier

2022-02-14 Thread OCsite via Webobjects-dev
Thanks to all for the answers!

Is there a way to use the ERExistsQualifier through 
qualifierWithQualifierFormat? At the particular place it would be somewhat 
difficult to create the qualifier tree programmatically, there are considerably 
more complex qualifiers ANDed and ORred to the thing, which I did not show for 
clarity, for they do not affect the problem.

(Also, it would be essentially impossible to do two fetches — the final 
qualifier is used through a WODisplayGroup).

Thanks a lot again,
OC
 
> On 15. 2. 2022, at 0:29, Samuel Pelletier  wrote:
> 
> Hi,
> 
> As Aaron wrote, ERExisitsQualifier will generate an SQL for your needs. You 
> may also change the JOIN type to change it's behaviour in SQL. EOF apply 
> table joins before qualifier, I suspect other ORM does the same too.
> 
> For that kind of quarry, you will probably have better performance doing 2 
> fetches and merge the results in memory. OR is an optimisation (index) killer 
> for SQL queries unless the interpreter is able to rewrite then as multiple 
> select using index with UNION
> 
> If your columns are not indexed, forget this comment, you are doing table 
> scan anyway,
> 
> Regards,
> 
> Samuel
> 
> 
>> Le 14 févr. 2022 à 10:05, Aaron Rosenzweig via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> a 
>> écrit :
>> 
>> Hi OC,
>> 
>> That’s called the object to relational impedance mismatch. The qualifier 
>> works in memory but fails when you try to invoke with SQL. 
>> 
>> To get around it, you can use an ERXExistsQualifier for your to-one 
>> relationship. Typically you use this with to-many relationships but it 
>> actually can work with to-one relationships too. The reason it works is 
>> because once inside the “exists” clause of SQL, it acts a bit like a 
>> namespace shield… in other words it’s not doing an inner-join so not 
>> negating things that you want to OR. 
>> 
>> Another possibility is to do multiple fetches. One with the attribute only. 
>> Then a second with the relationship only. Then merge the results. 
>> 
>> A third possibility is to not use an inner-join when mapping your PLIST in 
>> Entity Modeler, use one of the other join types… but that’s maybe not the 
>> best option unless you really know what you are doing. 
>> 
>> Personally, I’d give the Exists qualifier a try. 
>> 
>> Cheers,
>> — Aaron
>> 
>> 
>>> On Feb 14, 2022, at 1:13 AM, ocs--- via Webobjects-dev 
>>> mailto:webobjects-dev@lists.apple.com>> 
>>> wrote:
>>> 
>>> Hi there,
>>> 
>>> lately, I am encountering wrong fetches (with FrontBase, if important). I 
>>> log out my qualifier and SQL, and the gist of the problem is a join in the 
>>> OR-part of the qualifier. I want to fetch rows where there's an empty 
>>> attribute, OR when there's a specific join:
>>> 
>>> 06:52:06.510 DEBUG -> ((savedPresentationEndDate = null) or 
>>> (lastValidPriceOfferCache.user = (model.DBUser)'[rc/Registration 
>>> centre#104]'))
>>> 
>>> Alas, SQL-level, it boils down to something entirely different:
>>> 
>>> 06:52:06.535 DEBUG "DBAuction"@318794136 expression took 1 ms: SELECT ... 
>>> FROM "T_AUCTION" t0, "T_PRICE_OFFER" T1 WHERE (T1."C_CREATOR_ID" = 104 
>>> OR t0."C_PRESENTATION_END_DATE" is NULL) AND 
>>> t0."C_LAST_VALID_PRICE_OFFER_CACHE" = T1."C_UID"
>>> 
>>> The SQL generator properly sets up the OR checking the right target PK, but 
>>> then, instead of placing the join into the OR-part where it belongs to, it 
>>> forces the join absolute to the entire condition — even to the NULL-check 
>>> which should be completely independent.
>>> 
>>> That self-evidently is not what I need here: if 
>>> t0."C_PRESENTATION_END_DATE" is NULL, I want to fetch the row regardless of 
>>> whatever vaue there is or is not in the C_LAST_VALID_PRICE_OFFER_CACHE 
>>> foreign key. Actually, if there happens to be NULL in 
>>> C_PRESENTATION_END_DATE, I would prefer if the SQL-level would not try to 
>>> join at all, for it is self-evidently superfluous. I've tried manually
>>> 
>>> SELECT * FROM "T_AUCTION" t0, "T_PRICE_OFFER" T1 WHERE 
>>> (t0."C_PRESENTATION_END_DATE" is NULL) OR (T1."C_CREATOR_ID" = 104 AND 
>>> t0."C_LAST_VALID_PRICE_OFFER_CACHE" = T1."C_UID")
>>> 
>>> which is what, I  believe, the SQL generator should have created from the 
>>> qualifier, and it seems to work (at least, it produces no error; I cannot 
>>> easily check whether the rows returned are OK. but they seem to t the first 
>>> look).
>>> 
>>> Can perhaps anybody see how to fix the problem? (But for by generating 
>>> directly my SQL at the application level, which I can do if need be, but 
>>> would rather not, unless really the only way.)
>>> 
>>> Thanks,
>>> OC
>>> 
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>>> )
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple

restart problems

2022-01-29 Thread OCsite via Webobjects-dev
Hi there,

to keep at the safe side, we bounce our application once a day. The app happens 
to be somewhat specific in the sense it is really used only locally and at the 
business hours; therefore we can afford simply to not-gracefully relaunch it 
late evening.

Worked well for a long time. Lately the load increased, app worked, but got 
slow. We simply added memory, and it helped — the heavier load is served 
quickly and reliably.

What's weird is that the site administrators started to complaint that when 
there's a heavy load (served all right) during the day, the application does 
not relaunch properly at the evening. It looks like it hangs in some weird way; 
the admins have to notice and Force Quit, which reportedly works all right.

One thing is the question why not-graceful schedule might fail; we are 
investigating, looks like perhaps sometimes (for reasons yet unknown) a worker 
thread might lock (in a weird way similar to an endless loop, for we found no 
deadlock),  and that might prevent the relaunch.

The main question why I write: isn't there a way to tell wotaskd or JavaMonitor 
or whatever to try the normal schedule, but if it fails to re-launch properly 
in, say, half an hour, to automatically force quit and re-launch then? (And, 
preferably, send an e-mail to admins.)

I sort of recall I have read somewhere the Wonder wotaskd+JM should be able to 
do just that, but can't find the source whatever I try, nor I can find the 
appropriate option anywhere. (Truth is, deployment is not exactly my cup of tea 
and I can well be missing something of importance. Looks like, alas, the site 
admins still ask me, for I “know WebObjects” :))

Deploying on CentOS, if that is important.

Thanks,
OC ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: target-page-based (instead of hyperlink-based) fragment?

2022-01-16 Thread OCsite via Webobjects-dev
Jesse,

> On 16 Jan 2022, at 22:31, Jesse Tayler  wrote:
> ... using javascript to just store a scroll position on page exit

Strangely enough, that's what I've suggested as a probably simplest solution, 
but the client said “perhaps later, for now we want the proper anchor”.

It makes some sense, for the page contents (and thus also height of its parts) 
may change upon refresh — new objects to be shown, old ones disappear, etc. —, 
whilst an anchor position is well-defined through the page contents.

Hmmm, perhaps I should use JS to skip to the appropriate anchor upon a 
page-loaded event... might prove easier than somehow trying to stick the 
fragment to the URL...

Thanks and all the best,
OC

>> On Jan 16, 2022, at 3:53 PM, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> Hi there,
>> 
>> my client wants me to ensure that a page, when accessed/refreshed in any 
>> way, automatically scrolls to a specific place (which depends on previous 
>> usage of the thing).
>> 
>> Is there some place/hook in WebObjects which would allow me to automatically 
>> add a fragment (whose value is set up e.g., as 
>> component.currentFragmentIdentifier) to any URL which goes into that page, 
>> regardless the URL source?
>> 
>> Adding manually the fragment to all hyperlinks and forms which happen to 
>> lead to the particular page is conceptually possible, but lots of legwork I 
>> could do without, if there's another way to do that.
>> 
>> Thanks a lot,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com 
>> <https://lists.apple.com/mailman/options/webobjects-dev/jtayler%40oeinc.com>
>> 
>> This email sent to jtay...@oeinc.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


target-page-based (instead of hyperlink-based) fragment?

2022-01-16 Thread OCsite via Webobjects-dev
Hi there,

my client wants me to ensure that a page, when accessed/refreshed in any way, 
automatically scrolls to a specific place (which depends on previous usage of 
the thing).

Is there some place/hook in WebObjects which would allow me to automatically 
add a fragment (whose value is set up e.g., as 
component.currentFragmentIdentifier) to any URL which goes into that page, 
regardless the URL source?

Adding manually the fragment to all hyperlinks and forms which happen to lead 
to the particular page is conceptually possible, but lots of legwork I could do 
without, if there's another way to do that.

Thanks a lot,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: session/logged-in user valid for a specific component only?

2022-01-09 Thread OCsite via Webobjects-dev
Aaron,

thanks! Actually I could extend the user class easily, without a need to make a 
generic interface. Nevertheless I don't think either would help: in this 
particular case, the „canSeePage“ ability does not depend on the user, but only 
on whether the application has been connected to normally or through the 
specific DA. Thus it seems a bit more apt to store the ability to open the page 
session-level than user-level (although, of course, it would work too).

Thanks and all the best,
OC

> On 9 Jan 2022, at 17:28, Aaron Rosenzweig  wrote:
> 
> OC, your idea will work, but here’s another to consider. 
> 
> Make an interface for user objects, call it “UserInterface”
> 
> You are now free to have multiple types of user objects that all implement a 
> common interface. You can make your current User implement the interface and 
> now make a brand new User type for special access. 
> 
> In OCSComponent and your session, you work with objects of that interface. 
> 
> In OCSComponent make or modify “canSeePage()” method to know if a valid user 
> is authenticated and has ability to see the current page. Generally, it only 
> allows people of the old User type to access the page by default. 
> 
> In your new page, you can override “canSeePage()” to allow the new type of 
> User to have visibility. 
> 
>> On Jan 9, 2022, at 10:21 AM, ocs--- via Webobjects-dev 
>>  wrote:
>> 
>> Hi there,
>> 
>> I've got a pretty old application, the standard structure: there's Session 
>> which (among others) contains a property currentUser containing the user who 
>> has logged in and in whose account changes are performed. There is an 
>> OCSComponent extends ERXComponent with generic component services (many of 
>> which depend on session and/or its currentUser), and all my components 
>> inherit this.
>> 
>> Now I've got a new request to allow a given user to connect to _one specific 
>> page_ in the application through a specific URL _without a login_ and do his 
>> work in that page.
>> 
>> I can easily generate appropriate URL for a direct action, which would set 
>> up a session and open the desired page, that's easy.
>> 
>> What I can't quite see is how to prevent the user to go elsewhere in the 
>> application (e.g., by manually editing the URL) and stay logged in. Is there 
>> some trick for that?
>> 
>> So far I could think of two solutions:
>> 
>> (i) add a property allowedPage to Session, and in my direct action set it up 
>> appropriately. Then in the shared component awake at OCSComponent level I 
>> could check whether this==allowedPage and log out the user if not.
>> 
>> This looks like a good solution, but I am not entirely sure whether I am not 
>> overlooking some tricky way the user still might stay logged in and get to 
>> another page (without its awake performed)... is it completely safe?
>> 
>> (ii) write a complete new page code (ERXComponent-based, skipping 
>> OCSComponent altogether) for the specific page, which would contain and use 
>> its own component-level currentUser. The direct action would set this up and 
>> leave session.currentUser empty.
>> 
>> This is self-evidently completely safe, but a _lot_ of legwork :/
>> 
>> Can you see another, better solution? Or can you see that (i) is indeed safe 
>> enough?
>> 
>> Thanks and all the best (especially happy and successful new year),
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com
>> 
>> This email sent to aa...@chatnbike.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: session/logged-in user valid for a specific component only?

2022-01-09 Thread OCsite via Webobjects-dev
Markus,

thanks!

> On 9 Jan 2022, at 17:27, Markus Ruggiero  wrote:
> When you create your page inheriting from OCSComponent you inherit all the 
> methods including all managing your currentUser. Just override those. I would 
> think that solves your problem without too much of legwork.

Alas, the page (to which I need the special access) is not a new one to be 
created, but an existing non-trivial one; what's worse, it is not a direct 
subclass of OCSComponent, there's an intermediate class with another shared 
functionality. Aside of the inherited stuff, the page refers to the session 
both in its own code and also in the HTML template.

Thus, whilst this approach is technically possible, I am afraid it might prove 
more legwork than writing the component code afresh.

Unless hmmm, I wonder. Can I create an independent session for one specific 
page only this way?

===
class ThatDarnedComponent extends SomethingElse /* which extends OCSComponent 
which extends ERXComponent */ {
  Session specificPageOnlySessionAccess; // set up if no other page should 
share login
  Session session() {
return specificPageOnlySessionAccess?:super.session()
  }
  ... ... all the rest unchanged
===
class DirectAction extends WODirectAction {
  WOActionResult thatDarnedAction() {
def page=pageWithName("ThatDarnedComponent")
page.specificPageOnlySessionAccess=new Session() // not shared, but 
specific for the page only; other pages would get different session
page.specificPageOnlySessionAccess.currentUser=... user determined from 
request, details unimportant ...
return page
  }
  ... ...
===

Might that work perhaps? Would any other component (if accessed anyhow) get a 
different session? Or would there be problems due to the specific session 
somehow shared, e.g., through a context or whatever?

Thanks and all the best,
OC

>> On 9 Jan 2022, at 10:21, ocs--- via Webobjects-dev 
>>  wrote:
>> 
>> Hi there,
>> 
>> I've got a pretty old application, the standard structure: there's Session 
>> which (among others) contains a property currentUser containing the user who 
>> has logged in and in whose account changes are performed. There is an 
>> OCSComponent extends ERXComponent with generic component services (many of 
>> which depend on session and/or its currentUser), and all my components 
>> inherit this.
>> 
>> Now I've got a new request to allow a given user to connect to _one specific 
>> page_ in the application through a specific URL _without a login_ and do his 
>> work in that page.
>> 
>> I can easily generate appropriate URL for a direct action, which would set 
>> up a session and open the desired page, that's easy.
>> 
>> What I can't quite see is how to prevent the user to go elsewhere in the 
>> application (e.g., by manually editing the URL) and stay logged in. Is there 
>> some trick for that?
>> 
>> So far I could think of two solutions:
>> 
>> (i) add a property allowedPage to Session, and in my direct action set it up 
>> appropriately. Then in the shared component awake at OCSComponent level I 
>> could check whether this==allowedPage and log out the user if not.
>> 
>> This looks like a good solution, but I am not entirely sure whether I am not 
>> overlooking some tricky way the user still might stay logged in and get to 
>> another page (without its awake performed)... is it completely safe?
>> 
>> (ii) write a complete new page code (ERXComponent-based, skipping 
>> OCSComponent altogether) for the specific page, which would contain and use 
>> its own component-level currentUser. The direct action would set this up and 
>> leave session.currentUser empty.
>> 
>> This is self-evidently completely safe, but a _lot_ of legwork :/
>> 
>> Can you see another, better solution? Or can you see that (i) is indeed safe 
>> enough?
>> 
>> Thanks and all the best (especially happy and successful new year),
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/dominik.huber%40rucotec.ch
>> 
>> This email sent to dominik.hu...@rucotec.ch
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


again, merge on unlock did not happen :/

2021-10-07 Thread OCsite via Webobjects-dev
Hi there,

I am again here with a mysterious bug; something like this happened before 
(with slightly different setup), now it happened again. This time the 
attributes involved were NSTimestamps; I (might be wrong, but I) believe the 
attribute type is irrelevant to the problem and I am re-writing it below with 
strings for clarity. Happened under a non-trivial load, nevertheless, 
especially during the step (ii) below, nothing of importance happened in any 
other thread (one unlocked its EC, none other logged anything at all). Single 
OSC, single instance, no background threads (all the things below were normal 
R/R workers), nothing fancy at all.

The problem, cleaned up for clarity, looks like this:

(i) eoX.foo=="old", eoX.bar=="ok"; two session default ECs -- let's call them 
ecC[hanger] and ecO[bserver] -- have eoX in their registeredObjects

(ii) two intertwined threads do these operations in this order:
- ThrO: ecO.lock
- ThrC: ecC.lock
- ThrC: eoX.foo="new" (in ecC)
- ThrO: ecO changes other EOs which are not important for us; does not touch 
eoX at all
- ThrC: ecC.saveChanges (eoX.foo properly saved into DB as "new")
- ThrO: ecO.saveChanges (other EOs properly saved, no change of eoX, which is 
OK)
- ThrC: ecC.unlock
- ThrO: ecO.unlock

(iii) repeatedly happen these operations:
- ecO.lock
- ecO changes other EOs which are not important for us, never touches eoX
- ecO.saveChanges (other EOs properly saved, no change of eoX, which proves eoX 
was never in ecO.updatedObjects)
- ecO.unlock

(iv) after a while, eoX in ecO is used conceptually like this:
- ecO.lock
- if (eoX.foo=="old") eoX.bar="stale"
- ecO.saveChanges (saves into DB eoX.foo as "old" and eoX.bar as "stale")

Can you see any possible reason why on earth eoX.foo=="new" was not merged into 
ecO as a side-effect of its first (or any subsequent) lock in (iii)? Can you 
see any reasonable[1] way to prevent this kind of problems in future?

Alas creating a separate OSC for each session and syncing them manually is not 
really an option for me.

[1] I've considered to check all registeredObjects of any EC in each unlock, 
compare their values to the DB snapshot, if different, check whether they were 
locally updated in the EC, if not, (log a warning and) fix the local EC value 
from the snapshot. Does not seem to me reasonable though for (a) efficiency -- 
I fear it would take too much time -- and (b) a danger of unintended 
consequences (especially -- not only -- with unlocks during processing of the 
ObjectsChangedInStoreNotification I fear all hell would break loose if I try 
anything like that).

Thanks a lot,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


merging changes upon a save: what are “locally uncommitted changes”, too many snapshots?

2021-06-16 Thread OCsite via Webobjects-dev
Hi there,

is the process of merging changes upon a save into other ECs, and all the kinds 
of snapshots available, documented somewhere in detail?

My old EOEditingContextConcepts says just this:

... However, locally uncommitted changes to objects in the EOEditingContext are 
by default reapplied to the objects, in effect preserving the uncommitted 
changes in the object graph. After the update, the uncommitted changes remain 
uncommitted, but the committed snapshots have been updated to reflect the 
values in the EOObjectStore.

and I can't see what does it actually mean “locally uncommitted changes” here. 
Most probably a difference from some snapshot, but I admit I am sort of lost in 
the things.

So far I lived in impression that (if we ignore undo) there's only one kind of 
snapshots: OSC-level shared snapshots of what-was-just-saved-into-DB.

I've tried to research the thing a bit and there seem to be at the very least 
the following snapshots:

(i) EC.committedSnapshotForObject
(ii) EC.currentEventSnapshotForObject
(iii) EODatabaseContext.snapshotForGlobalID
(iv) EODatabaseContext.localSnapshotForGlobalID

I regret to say the standard documentation does not help much. I did some 
testing and it looks like

- (iii) is the one snapshot I knew: whenever save finishes, it always contains 
the newly saved values
- (i) and (ii) — which for me always contain same data, that's weird! — seem to 
contain an EC-level snapshot stored at its (first) willChange. Also it looks 
like those “locally uncommitted changes” are based on (one of) these. So far 
though I haven't found a case when (i) would differ from (ii)... although, 
based on the name, I would actually presume (i) should be the same as (iii). It 
very definitely is not.
- (iv) I don't understand at all :(

Are those things somewhere documented in detail?

Thanks and all the best,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: [WO-DEV] old/invalid :1 relationship value, how the H. possible?!?

2021-06-16 Thread OCsite via Webobjects-dev
Some followup: I have analysed the R/R loops in details and found that

- the user B saved changes at 11:00:25.220
- at this moment, there was a user A's R/R loop (which never touched the 
relevant data), running from 11:00:24.570 to 11:00:25.548
- the next user A's R/R loop started at 11:00:38.113, read the relevant data, 
did not see the changes of 11:00:25.220

In other words,
- at 11:00:25.220, user A's EC was locked; it should not merge the changes 
immediately...
- ... but, at 11:00:25.548 the user A's EC was unlocked: at this moment the 
11:00:25.220 changes should be merged into the EC...
- ... which self-evidently did not happen, for in the next R/R loop started at 
11:00:38.113 the 11:00:25.220 changes were still not visible.

How could that happen? What could prevent the merge at the EC unlock/RR loop 
end?

Thanks for any advice,
OC

> On 16 Jun 2021, at 6:35, OCsite  wrote:
> 
> Matthew,
> 
> no luck this way: one instance only, and one OSC 
> (ERXObjectStoreCoordinatorPool.maxCoordinators=1).
> 
> Thanks,
> OC
> 
>> On 16. 6. 2021, at 2:57, Matthew Ness > > wrote:
>> 
>> 
>> On Wed, Jun 16, 2021, at 1:42 AM, OCsite wrote:
>>> Hi there,
>>> 
>>> today we have bumped into a weird behaviour which I can't grok. We got an 
>>> old/invalid value for a :1 relationship to an important object (important 
>>> enough we even added its FK to the modelled locked attributes aside of the 
>>> PK; not that it helped any, but thanks to that, we see the current snapshot 
>>> values in the database operations).
>>> 
>>> 1. user A stored new object into the relationship; since we log all 
>>> database operations, we can see for his EC how this happened:
>>> 
>>> 11:00:12.995 UPDATE on 'DBAuction' ((uid = 1005602) and 
>>> (lastValidPriceOfferID = 1061694)) -> {lastValidPriceOfferID:1061695}
>>> 
>>> The saveChanges operation did not fail and the appropriate R/R loop did end 
>>> without a glitch, no exception, no problem at all, at 11:00:13.036.
>>> 
>>> 2. user B changed the object; again, we can see for his EC
>>> 
>>> 11:00:25.220 UPDATE on 'DBAuction' ((uid = 1005602) and 
>>> (lastValidPriceOfferID = 1061695)) -> {lastValidPriceOfferID:1061698}
>>> 
>>> The saveChanges operation again finished successfully and the appropriate 
>>> R/R loop did end all right at 11:00:25.424.
>>> 
>>> 3. in a new R/R loop which started at 11:00:40.947, user A read the value 
>>> (the very standard way through storedValueForKey('lastValidPriceOffer') — 
>>> which is the one we observe all the time, modelled as a simple :1 
>>> relationship with FK lastValidPriceOfferID) —, and got the stale object 
>>> PK:1061695! 
>>> 
>>> How is it possible that the step 2 did not update values in user A's EC? 
>>> Incidentally, to make extra sure we do not get stale values even if R/R 
>>> threads happen to overlap, the code uses in the step 3 looks like this:
>>> 
>>> synchronized (alock) { // lock for the DBAuction 1005602 object 
>>> (conceptually on PK to lock out all users regardless their ECs)
>>> try {
>>> auction.editingContext().unlock() // so as to process recent 
>>> changes from other ECs (thanks, Chuck!)
>>> auction.editingContext().lock()   // of course we have to keep 
>>> it locked
>>> DBPriceOffer wins=auction.lastValidPriceOffer() // simply calls 
>>> storedValueForKey('lastValidPriceOffer')
>>> println "... last valid $wins"
>>> 
>>> and this very log shows we have got the old price offer, the one with 
>>> PK:1061695.
>>> 
>>> I could understand this if user A changed the object to 1061695 and did not 
>>> save it (in which case the EC sync would not touch the change; but then it 
>>> would be all right, if the change was not saved), but he very definitely 
>>> did save the 1061695 successfully in step 1, and never changed it later 
>>> (until he got it again — the old/invalid value! — in step 3).
>>> 
>>> Can anyone see a scenario which would lead to him seeing still 1061695 in 
>>> step 3, regardless that
>>> - he did save it successfully at 11:00:12 and never changed it later;
>>> - another user did change it to 1061698 and successfully did save at 
>>> 11:00:25;
>>> - aside of the extra lock/unlock shown above, there is no manual EC 
>>> locking, ECs are auto-locked at R/Rs;
>>> - and besides, even if the extra lock/unlock was not used, the R/R threads 
>>> here did not overlap, so the change should be synced all right, and the 
>>> user should get 1061698 in the step 3?
>>> 
>>> What do I overlook?
>>> 
>>> Thanks and all the best,
>>> OC
>>> 
>> 
>> Hi,
>> 
>> How many instances of the application aretypically running?
>> 
>> Regards,
>> 
>> -- 
>> Matt
>> https://logicsquad.net 
>> https://www.linkedin.com/company/logic-squad/ 
>> 
 ___
Do not post admin requests to the list. They will be ignored.
Webob

given WOLips is being discussed...

2020-07-03 Thread OCsite via Webobjects-dev
... well, myself, I have found Eclipse next-to-unuseable (WOLips itself looked 
good, but it's, alas, Eclipse-based). In case there's more people similarly 
Eclipse-incompatible, let me just remind that the good ole XCode (with a couple 
of build scripts added) is considerably more convenient than Eclipse, and the 
only thing it can't do reasonably is EOmodelling.

Which is why there's a stand-alone EOModeller application, freely available at 
https://github.com/jvanek/EOModeler-OSX

(There's no graph view: for graph view you can use OmniGraffle, which still 
supports EOModels very nicely.)

All the best,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Creating a EOModel in code

2020-06-29 Thread OCsite via Webobjects-dev
Don,

> On 29 Jun 2020, at 17:16, Don Lindsay  wrote:
> Thanks for the information.  This may be the path I will need to go down for 
> this specific project.  

Good luck!

I have checked our sources and actually there were two small gotcha's we did 
bump into:

(i) programmatically added attributes are by default used for locking;
(ii) when adding new attribute, entity does not check whether its DB column is 
unique.

Both of these behaviours might well be intentional, but for us, both of them 
proved a bit at the surprising side. Given we do not run multi-instance, all we 
need to lock on are the PKs; and, we never share DB columns betwixt different 
attributes. Thus, we had to add extra code for both the cases.

Probably not the most elegant approach by far, but this works reliably for us 
for years (not pure Java, but I hope understandable without extra 
Groovy-explaining comments):

===
@Extension(EOEntity) class EntityExtensions {
... ...
void addAttributeIfNeeded(EOAttribute attr) {
EOAttribute old=this.attributeNamed(attr.name)
if (!old) {
EOAttribute clash=this.attributes.find { oa -> 
oa.columnName==attr.columnName }
if (clash) Exception.raise "cannot add attribute '$attr.name': 
column '$attr.columnName' already exists"
this.addAttribute(attr)
NSArray locks=this.attributesUsedForLocking()
if (locks.contains(attr)) {
locks.remove(attr)
this.attributesUsedForLocking=locks
}
return
}
String ocn=old.className(),ncn=attr.className()
if (ocn!=ncn) {
Class 
ocl=_NSUtilities.classWithName(ocn),ncl=_NSUtilities.classWithName(ncn)
if (ocl!=ncl) { // we may get same classes for different names, eg. 
String/NSString
if (!ocl) Exception.raise "no class for name '$ocn' attribute 
'$old.name'"
if (!ncl) Exception.raise "no class for name '$ncn' attribute 
'$attr.name'"
if (ncl !in ocl) Exception.raise "class '$ncl' incompatible 
with existing '$ocl' attribute '$attr.name'"
}
}
[
 'allowsNull','externalType','precision','scale',/*'width',*/ 
'adaptorValueClass', 'adaptorValueConversionClassName', 
'adaptorValueConversionMethodName', 'adaptorValueType', 'definition', 
'factoryMethodArgumentType', 'isReadOnly', 'prototypeName', 'readFormat', 
'relationshipPath', 'valueFactoryMethodName', 'valueType', 
'valueTypeClassName', 'writeFormat'].each { key ->
if (old."$key"!=attr."$key") {
Exception.raise "$key '",attr."$key","' differs from existing 
'"+old."$key"+"' attribute '$attr.name'"
}
}
}
}
===

All the best,
OC 

> 
> Thanks
> 
> Don 
> 
>> On Jun 29, 2020, at 07:14, OCsite mailto:o...@ocs.cz>> wrote:
>> 
>> Don,
>> 
>> we do something remotely similar all the time (not creating a complete 
>> model, but adding attributes dynamically at launch to entities). Works 
>> without a glitch, I cannot recall any problem at all with this.
>> 
>> Should work for you as well, I would be rather surprised if you encounter 
>> any problems model-side.
>> 
>> Potential problems might possibly occur at the database side: how do you 
>> read the schema in? We tried lots of things, eventually decided to stick 
>> with low-level DB-specific approach like e.g.,
>> 
>> def sch_list=EOUtilities.rawRowsForSQL(ec,model.name,'select "SCHEMA_PK", 
>> "SCHEMA_NAME" from INFORMATION_SCHEMA.SCHEMATA',null)
>> def table_list=EOUtilities.rawRowsForSQL(ec,model.name,/select "TABLE_PK", 
>> "TABLE_NAME" from INFORMATION_SCHEMA.TABLES where 
>> "SCHEMA_PK"=$schemaPK/,null)
>> 
>> and so forth, which seem to work reliably for our FrontBase. None of the 
>> higher-level APIs we have tried worked reliably for us (note though we not 
>> only read the schema in, but also need to add columns to tables dynamically; 
>> presumably, you won't need that).
>> 
>> All the best,
>> OC
>> 
>>> On 28 Jun 2020, at 17:51, Don Lindsay via Webobjects-dev 
>>> mailto:webobjects-dev@lists.apple.com>> 
>>> wrote:
>>> 
>>> Sorry if I was not clear in my first email.
>>> 
>>> I don’t want to create a EOModel file.  I want to take database connection 
>>> properties from the user of an application and use those to build an 
>>> EOModel that is used in the application while it is running on the server.  
>>> The database connection parameters would be stored in a settings database 
>>> and retrieved when the user wants to load data from that connection.  This 
>>> is a tool to allow users to specify their own data sources and compare data 
>>> between different datasources in whatever manner the user wishes to compare 
>>> or display it.
>>> 
>>> Thanks for all the answers so far I was not aware Apache Cayenne could be 
>>> used as a full replacement for EOF
>>> 
>>> Don 
>>> 
>>> 
 On Jun 25, 2020, at 20:53, Don Lindsay via Webobjects-dev 
 m

Re: Creating a EOModel in code

2020-06-29 Thread OCsite via Webobjects-dev
Don,

we do something remotely similar all the time (not creating a complete model, 
but adding attributes dynamically at launch to entities). Works without a 
glitch, I cannot recall any problem at all with this.

Should work for you as well, I would be rather surprised if you encounter any 
problems model-side.

Potential problems might possibly occur at the database side: how do you read 
the schema in? We tried lots of things, eventually decided to stick with 
low-level DB-specific approach like e.g.,

def sch_list=EOUtilities.rawRowsForSQL(ec,model.name,'select "SCHEMA_PK", 
"SCHEMA_NAME" from INFORMATION_SCHEMA.SCHEMATA',null)
def table_list=EOUtilities.rawRowsForSQL(ec,model.name,/select "TABLE_PK", 
"TABLE_NAME" from INFORMATION_SCHEMA.TABLES where "SCHEMA_PK"=$schemaPK/,null)

and so forth, which seem to work reliably for our FrontBase. None of the 
higher-level APIs we have tried worked reliably for us (note though we not only 
read the schema in, but also need to add columns to tables dynamically; 
presumably, you won't need that).

All the best,
OC

> On 28 Jun 2020, at 17:51, Don Lindsay via Webobjects-dev 
>  wrote:
> 
> Sorry if I was not clear in my first email.
> 
> I don’t want to create a EOModel file.  I want to take database connection 
> properties from the user of an application and use those to build an EOModel 
> that is used in the application while it is running on the server.  The 
> database connection parameters would be stored in a settings database and 
> retrieved when the user wants to load data from that connection.  This is a 
> tool to allow users to specify their own data sources and compare data 
> between different datasources in whatever manner the user wishes to compare 
> or display it.
> 
> Thanks for all the answers so far I was not aware Apache Cayenne could be 
> used as a full replacement for EOF
> 
> Don 
> 
> 
>> On Jun 25, 2020, at 20:53, Don Lindsay via Webobjects-dev 
>>  wrote:
>> 
>> Hello;
>> 
>> The Documentation for EOModel states that you can build one in code, but 
>> there are no examples or further information that I can find.  Does anyone 
>> have any documentation or samples that they can direct me to so I can create 
>> EOModels while the application is running:
>> 
>> What I want to do is connect to a database that my app does not know about, 
>> someone provides connection parameters and I create an EOModel and connect 
>> to that database or rest and access it using the EOModel created using new 
>> EOModel().
>> 
>> Thanks
>> 
>> Don
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/pccdonl%40me.com
>> 
>> This email sent to pccd...@me.com
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


GID for deleted objects

2020-06-15 Thread OCsite via Webobjects-dev
Hi there,

I've just bumped into another problem which seems it should be pretty common, 
but I can't see a decent solution (due to my blindness quite probably).

I am caching some information for EOs; the info is EC-independent, and 
therefore the cache is keyed by global IDs.

When an EO is successfully deleted, I want to remove the info from the cache. 
Thus, the cache observes EditingContextDidSaveChangesNotification and would 
remove the userInfo[EOObjectStore.DeletedKey] objects.

The problem is that these objects are already unregistered from the EC and I 
can't get their GIDs anymore.

Is there a decent known solution of this problem? I probably can do something 
like storing GIDs of objects which are only being deleted somewhere and use 
these stored GIDs later when the deletion succeeds, but that seems to be rather 
at the complex and awkward side for a conceptually simple operation. Do I 
overlook some simpler solution, or is this indeed the only way?

Thanks,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Entity/attribute/relationship terrible toString?

2020-06-02 Thread OCsite via Webobjects-dev
Markus,

> On 2 Jun 2020, at 12:09, Markus Ruggiero  wrote:
> Why not simply override toString() in EOGenerate templates once and for all?

What are “EOGenerate templates” and how they affect the 
entities/attributes/relationships toStrings? I can't find anything like that in 
my WO documentation. Seems it might be the right solution... if I knew what it 
is :)

Thanks!
OC

> 
>> On 2 Jun 2020, at 01:52, ocs--- via Webobjects-dev 
>>  wrote:
>> 
>> Hi there,
>> 
>> occasionally, I need to put entities/attributes/relationships into complex 
>> nested property lists. Occasionally for debug, I need to print out these 
>> property lists.
>> 
>> Alas, entities/attributes/relationships normally print out their complete 
>> contents in their toStrings, which makes the logs completely unuseable (and 
>> when there's more of them in a property list, actually bogs down the 
>> application so much it must be killed).
>> 
>> Isn't there some trick to make those darned model classes toString something 
>> reasonable, e.g., just their class, name and hash?
>> 
>> Thanks,
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/steiner%40rucotec.ch
>> 
>> This email sent to stei...@rucotec.ch
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


EC locking/shared snapshots/old data saved

2020-05-29 Thread OCsite via Webobjects-dev
Hi there,

just again, I've been bit in my tender parts by the well-known problem that

1. thread A locks its EC
2. thread B saves some change into DB
3. thread A saves its own changes (of different properties), which alas as a 
side-effect also reverts B's changes ...

... since A's EC still contains the state before B's changes, and when that 
state is compared with the shared snapshot (updated in step 2), the original 
outdated object state before B's changes looks like a new change done by A and 
thus is saved.

Isn't there some general solution of this problem? I can think of at least 
three:

(a) always unlock (and immediately re-lock) EC before saving, preferably 
directly in the ERXEC.saveChanges() code (resp. overridden saveChanges of my 
own ERXEC subclass, set as er.extensions.ERXEC.editingContextClassName). That, 
far as I understand, would merge all the other changes (of which EOF already 
well knows due to the notifications, but it can't merge them whilst the EC is 
locked).

That would be pretty easy to do, but I am not sure of other dangers which it 
possibly might bring? There could be plenty, I am afraid.

(b) implement EC-based non-shared snapshots and use them instead of (or rather 
along with) the shared ones to determine what to save into the DB.

That would be considerably more work, again with possible dangers which I can't 
quite see now.

(c) invent a scheme with timestamps attached to individual properties in 
shapshots and compare them, letting the newest win.

Probably too much at the rube-goldbergish side to be practical.

Has somebody already tried and tested either (a) or (b) or (c) or any other 
approach, better than those three, to alleviate this kind of problems with a 
success?

Thanks,
OC ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


dedlock report whenever app ends?

2020-05-21 Thread OCsite via Webobjects-dev
A propos of

> alas, the site admins did not try to ask JVM to detect deadlocks when they 
> restarted the application

might it perhaps to be possible to set something somewhere up so that each time 
a WO application is stopped by the JavaMonitor, the JVM always tries to detect 
and log out into the application log any deadlocks, far as reasonably possible 
(something like jstack being always auto-launched on the process just before it 
quits)?

Thanks,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: background tasks locked, workers run all right

2020-05-21 Thread OCsite via Webobjects-dev
Aaron,

thanks a lot!

> On 21 May 2020, at 17:30, Aaron Rosenzweig  wrote:
> It looks like you are mixing a couple things.

Well probably I miss something of importance here.

> If you are going to use Kieran’s code (I believe it was him initially) you 
> should use it fully and have a healthy number of coordinators

If “the Kieran’s code” is exploiting of 
ERXObjectStoreCoordinatorPool.maxCoordinators > 1, well, we actually do not 
want to do that. We do that in other applications, but not in this one.

Part of the normal processing which we do is locking the (one and only one) 
shared OSC to make sure some of the actions are well-serialised — it's more 
important than the speed. For normal processing (of page actions through R/R 
loops and their working threads) this causes no problem, quite the contrary, 
it's precisely what we want.

Contrariwise, those import tasks are special for they (a) run with very low 
priority, (b) should not be affected by the main OSC lock (nor affect it and 
its users) at all. Thus...

> I say that because his code does round robin and there is a chance that two 
> threads get the same coordinator under heavy load so you better stock up on 
> them. Think of each coordinator as a single cursor to the DB.

... creating a new coordinator for each import thread as “its own cursor to the 
DB” (or more precisely, its own EOF stack pretty independent on all the others) 
is precisely what I want.

Actually those import tasks could be ideally run from another application or at 
least instance; only it would be a bit at the inconvenient side :)

Is that wrong? Why?

> For some reason you are telling Kieran’s code to only have one coordinator. 
> Then, on top of that, you make your own coordinator each time. It’s like 
> crossing the beams in Ghostbusters. Go one way, or the other, don’t mix.

Probably I misunderstood the Kieran's code mightily.

I do not need a coordinator pool far as I can say, and but for the default one 
OSC (which is shared by all the normal processing threads and ECs), I do not 
want coordinators reused, ever.

Normally, there's at most one import task at given time (and they happen to be 
rather infrequent); nevertheless, if due to some extremely rare conditions it 
so happens and more imports runs at once, I'd still prefer each of them to have 
its own EOF stack/DB access, independent on all the others.

> There is something to be said about rolling your own and ensuring every 
> thread has their own coordinator and then you don’t even need to lock.

Yup, far as I understand, in this case, when the thread has its own EC in its 
own OSC none of which is ever shared with other threads, I believe locking in 
superfluous (but at the same time, harmless).

> You would also want a queuing mechanism so that you don’t create too many 
> coordinators.

Aside of the memory consumption (which we keep track of and is not too bad), 
why? In theory I can see the DB might reject too many connections, but that 
would hardly happen. Even if it did, I presume the fetch would thrown, not 
block?!?

> If you are are not going to do that and want the easy button, embrace 
> Kieran’s code fully by making a large pool and letting his code give you an 
> EC to work with.

Correct me please if I am wrong, but far as I understand, this could lead to 
the import EC sharing the OSC with some of normal sessions/worker threads, and 
that's definitely something we do not want to.

I can add extra code to make sure it does not happen and to make sure sessions 
get one OSC and threads get others, but what would then be the advantage of 
that compared with creating one OSC for each import thread?

> Think about how many people you expect to be using a long running task 
> concurrently and at least double that number for your pool size.

In which case, what's precisely the advantage of having a pool instead of 
creating a new OSC for each import thread (and releasing it when the import is 
done)?

> Don’t forget to send him some Red Breast Whiskey. 

Aha! At least one thing which I do not need more detailed elucidation :)

Thanks again,
OC

>> On May 21, 2020, at 7:13 AM, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> bumped lately into another weird problem. We import some data into DB in 
>> background tasks. Up to yesterday, it worked normally; today six import 
>> tasks were launched, and each of them seemingly hang in its first DB 
>> operation. Restart did help; alas, the site admins did not try to ask JVM to 
>> detect deadlocks when they restarted the application.
>> 
>> The background task looks like this:
>> 
>> ===
>> class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation {
>> def performAction {
>> _thread.priority=Thread.M

background tasks locked, workers run all right

2020-05-21 Thread OCsite via Webobjects-dev
Hi there,

bumped lately into another weird problem. We import some data into DB in 
background tasks. Up to yesterday, it worked normally; today six import tasks 
were launched, and each of them seemingly hang in its first DB operation. 
Restart did help; alas, the site admins did not try to ask JVM to detect 
deadlocks when they restarted the application.

The background task looks like this:

===
class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation {
def performAction {
_thread.priority=Thread.MIN_PRIORITY
try {
try {
editingContext=ERXEC.newEditingContext(objectStore=new 
EOObjectStoreCoordinator())
editingContext.lock()
lognow 1, "=== preparing CSV import in EC $editingContext ==="

formPrototype=ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(editingContext,formPrototypeGID)
lognow 1, "=== local prototype $formPrototype ==="
... ...
===

Always the “preparing” log was the last thing those threads presented; none of 
them ever reported “local prototype”. There's no other related log in there.

Meantime the application ran normally and the worker tasks communicated with 
the database all right (with an occasional report that some select took 70-odd 
ms from ERXAdaptorChannelDelegate, we have the threshold at 50). We run with   
ERXObjectStoreCoordinatorPool.maxCoordinators=1.

Any idea what could have gone wrong and how to find the culprit and prevent the 
problem in future? I thought a new EC in a new OSC can't be blocked for long, 
but self-evidently, I was wrong, they seemed to lock indefinitely (application 
was restarted ten-odd hours after the first import hanged after its “preparing” 
report, still no “local prototype”).

Thanks and all the best,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: SQL Error on fetch

2020-02-04 Thread OCsite via Webobjects-dev
Gino,

I can be completely wrong, but it looks like two problem logs interspersed, 
which stinks by a threading issue, along with the fact it happens 
intermittently.

If possible, I'd check race conditions and try to synchronize (or lock) where 
needed.

Quite possibly someone other would give a much better advice, just a quick-look 
idea.

All the best,
OC

> On 4 Feb 2020, at 22:00, Gino Pacitti via Webobjects-dev 
>  wrote:
> 
> Hi 
> Has anyone encountered this sort of error before?
> 
> It does not happen all the time but just on occasion.
> 
> mysql  Ver 14.14 Distrib 5.7.28, for Linux (x86_64) using  EditLine wrapper
> 
> Java 8
> 
> mysql-connector-java-8.0.19.jar
> 
> This is my connection URL
> jdbc:mysql://127.0.0.1/_UTF_8?capitalizeTypeNames=true&useUnicode=true&characterEncoding=UTF-8&characterSetResults=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&sendFractionalSeconds=false&autoReconnect=true&useServerPrepStmts=false&rewriteBatchedStatements=true&useCompression=true
>  
> 
> 
> And here is the error
> Unexpected exception encountered during 
> query.java.lang.NullPointerExceptionat 
> com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)com.mysql.jdbc.SQLError.createSQLException(SQLError.java:965)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:898)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:887)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:861)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2532)
> at 
> com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1903)
> at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1242)
> at 
> com.webobjects.jdbcadaptor.JDBCChannel._bindInputVariablesWithBindingsAndExecute(JDBCChannel.java:265)
> at 
> com.webobjects.jdbcadaptor.JDBCChannel._evaluateExpression(JDBCChannel.java:337)
> at 
> com.webobjects.jdbcadaptor.JDBCChannel.evaluateExpression(JDBCChannel.java:296)
> at 
> er.extensions.jdbc.ERXJDBCAdaptor$Channel.evaluateExpression(ERXJDBCAdaptor.java:283)
> at 
> com.webobjects.jdbcadaptor.JDBCChannel.selectAttributes(JDBCChannel.java:220)
> at 
> er.extensions.jdbc.ERXJDBCAdaptor$Channel.selectAttributes(ERXJDBCAdaptor.java:200)
> at 
> com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificationEditingContext(EODatabaseChannel.java:897)
> at 
> com.webobjects.eoaccess.EODatabaseChannel.selectObjectsWithFetchSpecification(EODatabaseChannel.java:234)
> at 
> com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEditingContext(EODatabaseContext.java:3055)
> at 
> com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(EODatabaseContext.java:3195)
> at 
> com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecification(EOObjectStoreCoordinator.java:488)
> at 
> com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:4069)
> at er.extensions.eof.ERXEC.objectsWithFetchSpecification(ERXEC.java:1307)
> at 
> com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java:)
> at 
> er.extensions.eof.ERXFetchSpecification.fetchObjects(ERXFetchSpecification.java:155)
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


REDIRECTED to non-refusing instance

2020-02-03 Thread OCsite via Webobjects-dev
Hi there again,

is there any known situation/bug, which would lead to the logs of kind

DEBUG !!! Request will be REDIRECTED to non-refusing instance

without having set either Refuse new session or graceful scheduling in the JM?

I have found a debate in which Chuck asserts that WO might have long ago (WO 
5.1/2, 2003) contained a bug which would lead to this log when a direct action 
URL contains a session ID; but far as I understand properly, even thus it still 
would happen with Refuse/Graceful only, neither of which we use.

Thing is, we are lately getting lots of those REDIRECTED logs now at our 
production server (not surprisingly it never happens at the test site). It 
seems to be coming with a new version of the application, but none of the 
changes in the code, far as I can say, seems to be remotely relevant to such a 
problem.

Thanks!
OC




 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


JavaScripts generated programmatically and/or placed at the end

2020-01-26 Thread OCsite via Webobjects-dev
Hi there,

for once, no deep mystery, but a plain API-related question :)

I am just switching my old very hap-hazard and ugly way of loading javascripts 
as needed by components to the very neat ERXComponent's support of 
additionalJavascriptFiles. Mostly it works like a charm, but for two cases:

(i) scripts which are generated programmatically

So far, I have used directly in the particular component template something like

===



===

Is there a way to exploit somehow the ERXComponent's support for that, to move 
these scripts to the  too?

(ii) scripts which need to be placed at the end of page

Far as I was able to ascertain, all the  tags for the scripts from 
additionalJavascriptFiles are always generated to . Mostly it's precisely 
what I need, but time to tome, the script needs to be placed at the end of page 
(for it runs something which addresses the page elements). Is there a way to 
use the ERXComponent's support for that?

Thanks a lot,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Failed Query

2020-01-14 Thread OCsite via Webobjects-dev
Gino,

first thing I would try would be to log out the generated SQL and check its 
contents. Can you do that?

Unless I am missing something, your quoted strings look like a plain ASCII, and 
thus they should not be affected by Unicode quirks.

All the best,
OC

> On 14 Jan 2020, at 15:26, Gino Pacitti via Webobjects-dev 
>  wrote:
> 
> Still not working ….
> 
> Could it be the length of the string?
> 
> This is the searched for String -  pi_1G0qENIo1HLeQd0O7rTZlOAx
> 
> This is the database Varchar -pi_1G0qENIo1HLeQd0O7rTZlOAx
> 
> I have this in my connection Dictionary - 
> useUnicode=true&characterEncoding=UTF-8
> 
> The database is configured for UTF-8 and the column has this Collation - 
> utf8_general_ci  
> 
> The search for string is returned from a POJO 
> 
> Any other ideas?
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On 14 Jan 2020, at 12:59, Gino Pacitti via Webobjects-dev 
>>  wrote:
>> 
>> Thanks Pierre
>> 
>> I will test this out…
>> 
>> 
>> 
>>> On 14 Jan 2020, at 12:57, GILQUIN Pierre  wrote:
>>> 
>>> Yes strange 
>>> 
>>> A case issue ? May be try  Transaction.PAYMENTINTENTID.ilike()
>>> Or a encoding utf8/iso issue …
>>> 
>>> 
>>> 
>>> De : Webobjects-dev 
>>> [mailto:webobjects-dev-bounces+pierre.gilquin=hcuge...@lists.apple.com] De 
>>> la part de Gino Pacitti via Webobjects-dev
>>> Envoyé : mardi 14 janvier 2020 13:34
>>> À : WebObjects-Dev Mailing List List
>>> Objet : Re: Failed Query
>>> 
>>> Thanks I will give it a go…
>>> 
>>> Funny thing is that the ‘old’ code works and then just on occasion does not…
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 14 Jan 2020, at 12:25, GILQUIN Pierre via Webobjects-dev 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> I Dont know if your old style qualifier is correct, so you may try 
>>> something like this with the corresponding ERXKey :
>>> myQual  = Transaction.PAYMENTINTENTID.eq(paymentIntentID) ;
>>> 
>>> De : Webobjects-dev 
>>> [mailto:webobjects-dev-bounces+pierre.gilquin=hcuge...@lists.apple.com] De 
>>> la part de Gino Pacitti via Webobjects-dev
>>> Envoyé : mardi 14 janvier 2020 13:04
>>> À : WebObjects-Dev Mailing List List
>>> Objet : Failed Query
>>> 
>>> Hi 
>>> Anyone had experience of queries that should return an object as the row 
>>> exists but EOF throws a NoSuchElementException?
>>> 
>>> This is some code:
>>> 
>>> 
>>> Transaction transactionEo = 
>>> QueryDatabase.TransactionForPaymentIntentIdQuery(customCharge.getPayment_intent(),
>>>  _ec);
>>> 
>>> 
>>> public static synchronized Transaction 
>>> TransactionForPaymentIntentIdQuery(String paymentIntentID, EOEditingContext 
>>> _ec) throws NoSuchElementException {
>>> 
>>> 
>>>NSArray args = new NSArray(new String[]{  
>>> paymentIntentID  });
>>>EOQualifier myQual = 
>>> EOQualifier.qualifierWithQualifierFormat("purchaseIntentId = %@", args);
>>> 
>>>log.info("Qualifier " + myQual);
>>> 
>>> 
>>>return Transaction.fetchRequiredTransaction(_ec, myQual);
>>> 
>>>  }
>>> 
>>> ___
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40mac.com
>>> 
>>> This email sent to ginok...@mac.com
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40mac.com
>> 
>> This email sent to ginok...@mac.com
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

2020-01-14 Thread OCsite via Webobjects-dev
Chuck,

> On 14 Jan 2020, at 6:31, Chuck Hill  wrote:
> On Jan 13, 2020, at 5:42 AM, OCsite mailto:o...@ocs.cz>> wrote:
>>> Do you have multiple EOF stacks (multiple EOObjectStoreCoordinator 
>>> instances)?
>> 
>> Hmmm... yup, in most of my apps, I use for years and years
>> 
>> er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=3
>> 
>> Let me see, I'll try without ... and just again, you are right! When this is 
>> commented out from Properties, relationships to SEC get saved properly 
>> (without the convoluted databaseContextWillOrderAdaptorOperations delegate 
>> of course).
>> 
>> Can you please explain how this relates? I must be missing something of 
>> importance, but I can't see any sense in that :( How on earth might the sole 
>> existence of a couple of other (far as I know, pretty independent) EOF 
>> stacks affect the way an EODBOp creates its newRows?!? :-O
> 
>  I’ve never been much of an SEC user.  The EOSharedEditingContext is an 
> EOEditingContext and so it is associated with one EOObjectStoreCoordinator.  
> What I will guess is that the OSC of the SEC instance is != the OSC of the 
> EOEditingContext you are using and there is a bug because the relationship 
> crosses OSCs.  I doubt that is fixable, but you might find some way to use 
> that to come up with a better hack.  Assuming that I am correct.

As always, indeed, correct you are.

Since my app makes sure to use only one of all the coordinators for the normal 
work and for sessions (keeping the rest of coordinators from the pool solely 
for my background tasks), I was pretty sure this can't happen... until I tried 
to log out the coordinators, and indeed, they did differ. Seems the SEC 
coordinator gets assigned in some weird way.

With fixing, I am afraid I am outta luck; one possibility would be to get rid 
of the SEC altogether, another probably the delegate hack which works around 
the problem — for having revisited the app meantime, alas, I recalled I can't 
do without those extra coordinators for the background tasks. Some of them 
could write many objects into DB, and alas, I can't let the users in normal 
sessions wait for that long :(

>> I do wonder of the speed difference in practice: one coordinator would 
>> definitely make the app somewhat slower; on the other hand, SEC itself 
>> should speed it up, removing a need of many DB roundtrips... hm, perhaps it 
>> would be better just to forget maxCoordinators and stay at the safe side.
> 
> There is some EO cache in Wonder that I have used instead of the SEC to keep 
> EOs easy to get.  I forget the name now.  It is not quite as convenient but 
> less magic might yield better results.

For the moment, I am using both. The EO cache you mean would probably be 
ERXEnterpriseObjectArrayCache? I am using the thing pretty widely to cache 
normal EOs to lower the number of DB roundtrips needed (nevertheless it seems 
the turning the cached GIDs to objects is rather at the slow side too, and I am 
considering to extend the code to try to cache the objects themselves while 
there's a memory galore in some sort of a weak map — incidentally, to all, has 
someone already tried that? I haven't found this kind of cache in ERX; either 
it does not exist, or I have searched improperly.)

SEC serves for my „static“ objects, which are never changed (more precisely, 
they might be changed in a special task upon launch, before the first session 
is created; and never ever again). A majority of these „static“ objects then 
are shared by essentially all sessions — in my current application there's lots 
of those, which is also the very reason I have started to use SEC at all (for 
the first time in twenty-odd years of using WO ;))

For this very reason I would rather like to keep the SEC, far as it proves 
manageable; but of course, we'll see...

> This might be of use too:
> https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Caching_and_Freshness#EOEntity's_Cache-In-Memory_Setting
>  
> <https://en.wikibooks.org/wiki/WebObjects/EOF/Using_EOF/Caching_and_Freshness#EOEntity's_Cache-In-Memory_Setting>
Thanks! I have considered that, too; but I have eventually chosen SEC because 
it not only caches, but also ensures the objects are actually shared betw. all 
sessions. Far as I understand, in-memory entities would cause each session to 
have its own full cache of all the „static“ objects, which might be a bit of a 
memory problem with more users working with the app at once.

Perhaps it was a wrong decision and the memory waste would be a cost well worth 
of not bumping into those SEC quirks...

Thanks again,
OC

>>>> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
>>>> mailto:webobjects-dev@lists.apple.c

Definitely solved: More SharedEC woes: relationships into SEC not saved with more EOF stacks

2020-01-13 Thread OCsite via Webobjects-dev
Chuck,

> On 13 Jan 2020, at 4:17, Chuck Hill  wrote:
> There must be something going on here that you are not mentioning.

Definitely there is, but I had no idea what might be the culprit. Now I see 
(but still don't quite understand).

> Do you have multiple EOF stacks (multiple EOObjectStoreCoordinator instances)?

Hmmm... yup, in most of my apps, I use for years and years

er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=3

Let me see, I'll try without ... and just again, you are right! When this is 
commented out from Properties, relationships to SEC get saved properly (without 
the convoluted databaseContextWillOrderAdaptorOperations delegate of course).

Can you please explain how this relates? I must be missing something of 
importance, but I can't see any sense in that :( How on earth might the sole 
existence of a couple of other (far as I know, pretty independent) EOF stacks 
affect the way an EODBOp creates its newRows?!? :-O

Pity I did not know sooner; perhaps I would just switch to use one stack and 
save myself all the effort with the searching for the culprit, delegate fixes 
attempt etc.

I do wonder of the speed difference in practice: one coordinator would 
definitely make the app somewhat slower; on the other hand, SEC itself should 
speed it up, removing a need of many DB roundtrips... hm, perhaps it would be 
better just to forget maxCoordinators and stay at the safe side.

Thanks again a very big lot!
OC

>> On Jan 12, 2020, at 4:13 PM, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> I think I have probably solved the original problem (quoted below) all 
>> right, for the record, by doing essentially this in the 
>> databaseContextWillOrderAdaptorOperations delegate method:
>> 
>> 1. go through all the database operations; for each of them
>>   2. go through all the relationships of the DBOp object; find those which 
>> lead into SEC
>> 3. for each such relationship check whether changesFromCommittedSnapshot 
>> contain a value for its name
>> 4. if so, check whether DBOp's rowDiffs have the proper target PK[*] for 
>> the rel source attribute name (it never seems to happen!)
>> 5. if not, add it to a mutable copy of DBOp's newRow
>>   6. having processed all the rels, if anything was added, change DBOp's 
>> newRow and call the DBContext private (ick!) method 
>> createAdaptorOperationsForDatabaseOperation
>> 7. having processed all the DBOps, call the DBContext private (another ick) 
>> method orderAdaptorOperations and return its value from the delegate method.
>> 
>> [*] my models happen to contain only simple FK->PK relships to SEC; 
>> considerably more generic and complex code would be needed for all the 
>> possible cases of course.
>> 
>> That seems to — with by far not exhaustive testing — save the changes into 
>> the database properly.
>> 
>> Quite non-trivial code for simple 
>> saving-of-relationship-as-set-in-object-graph-into-DB.
>> 
>> I wonder. Is it perhaps a big no-no to use and edit relationships from 
>> normal ECs into the SEC? I thought those are fully supported (unlike the 
>> other direction). Or do I just do something terribly wrong somewhere in my 
>> application, for this should work all right?
>> 
>> Does anyone here use this setup (creating/updating EOs with one-way 
>> relationships into SEC), and does it work properly for you without all this 
>> hassle?
>> 
>> Thanks,
>> OC
>> 
>> 
>>> On 11 Jan 2020, at 3:28, OCsite via Webobjects-dev 
>>> mailto:webobjects-dev@lists.apple.com>> 
>>> wrote:
>>> 
>>> Hi there,
>>> 
>>> this is weird. My EOs have some relationships into the SharedEC — of 
>>> course, one-way without an inverse; I understand that relationships to SEC 
>>> are all right, only those from it outside are forbidden. (Am I wrong 
>>> perhaps? If those relationships were set up in the database without SEC, it 
>>> works perfectly.)
>>> 
>>> Nevertheless, when I run with SEC, whatever I try, it seems these 
>>> relationships are — silently and without reporting any problem — not saved.
>>> 
>>> Say, I have an EO foo of entity Foo with two simple :1 relationships: a 
>>> (based on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a 
>>> shared-EC entity. Both are modelled the same way (simple join from the FK 
>>> in the source entity to the PK of the target entity). I set both of them, 
>>> like this:
>>> 
>>> ===
>>> ERXEC ec=
>>>

Hopefully solved: More SharedEC woes: relationships into SEC not saved?!?

2020-01-12 Thread OCsite via Webobjects-dev
I think I have probably solved the original problem (quoted below) all right, 
for the record, by doing essentially this in the 
databaseContextWillOrderAdaptorOperations delegate method:

1. go through all the database operations; for each of them
  2. go through all the relationships of the DBOp object; find those which lead 
into SEC
3. for each such relationship check whether changesFromCommittedSnapshot 
contain a value for its name
4. if so, check whether DBOp's rowDiffs have the proper target PK[*] for 
the rel source attribute name (it never seems to happen!)
5. if not, add it to a mutable copy of DBOp's newRow
  6. having processed all the rels, if anything was added, change DBOp's newRow 
and call the DBContext private (ick!) method 
createAdaptorOperationsForDatabaseOperation
7. having processed all the DBOps, call the DBContext private (another ick) 
method orderAdaptorOperations and return its value from the delegate method.

[*] my models happen to contain only simple FK->PK relships to SEC; 
considerably more generic and complex code would be needed for all the possible 
cases of course.

That seems to — with by far not exhaustive testing — save the changes into the 
database properly.

Quite non-trivial code for simple 
saving-of-relationship-as-set-in-object-graph-into-DB.

I wonder. Is it perhaps a big no-no to use and edit relationships from normal 
ECs into the SEC? I thought those are fully supported (unlike the other 
direction). Or do I just do something terribly wrong somewhere in my 
application, for this should work all right?

Does anyone here use this setup (creating/updating EOs with one-way 
relationships into SEC), and does it work properly for you without all this 
hassle?

Thanks,
OC


> On 11 Jan 2020, at 3:28, OCsite via Webobjects-dev 
>  wrote:
> 
> Hi there,
> 
> this is weird. My EOs have some relationships into the SharedEC — of course, 
> one-way without an inverse; I understand that relationships to SEC are all 
> right, only those from it outside are forbidden. (Am I wrong perhaps? If 
> those relationships were set up in the database without SEC, it works 
> perfectly.)
> 
> Nevertheless, when I run with SEC, whatever I try, it seems these 
> relationships are — silently and without reporting any problem — not saved.
> 
> Say, I have an EO foo of entity Foo with two simple :1 relationships: a 
> (based on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a 
> shared-EC entity. Both are modelled the same way (simple join from the FK in 
> the source entity to the PK of the target entity). I set both of them, like 
> this:
> 
> ===
> ERXEC ec=
> Foo foo=new Foo()
> ec.insertObject(foo)
> assert ec==someObject.editingContext()
> foo.a=someObject
> assert ec.sharedEditingContext()==someSharedObject.editingContext()
> foo.b=someSharedObject
> assert foo.b==someSharedObject
> ec.saveChanges()
> ===
> 
> Now, changes are saved, no error is reported, new object is properly inserted 
> into the database
> - its a_id is filled by someObject's PK
> - whilst its b_id is filled by NSKeyValueCoding$Null!
> 
> Same happens when editing: the relationships to SEC when changed never seem 
> to save the appropriate FK value. It seems completely ignored by the saving 
> process:
> 
> ===
> assert 
> foo.editingContext().sharedEditingContext()==anotherSharedObject.editingContext()
> foo.b=anotherSharedObject
> assert foo.b==anotherSharedObject
> assert foo.committedSnapshotValueForKey('b')==NSKeyValueCoding$Null
> assert foo.changesFromCommittedSnapshot==[b: anotherSharedObject]
> foo.editingContext().saveChanges()
> assert foo.b==null
> ===
> 
> other changes of foo (if any) are saved all right, but its b_id never 
> changes. No error is reported.
> 
> Does this make any sense, is it perhaps an expected behaviour? As always, I 
> might be overlooking something of importance, but this feels completely wrong 
> to me. Could it be caused by some bug at my side? If so, any idea where and 
> how to hunt for it?
> 
> Thanks a lot for any insight,
> OC
> 
> ___
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
> 
> This email sent to o...@ocs.cz

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: More SharedEC woes: relationships into SEC not saved?!?

2020-01-12 Thread OCsite via Webobjects-dev
Chuck,

> On 12 Jan 2020, at 21:01, Chuck Hill  wrote:
> It only works for code that does  _NSUtilities.classForName().  It only works 
> for code that defers knowing the class based on a string.

I see, so it is the dictionary approach after all. I somewhat hoped they might 
have tweaked the classloader, so that I would be able to patch any class, if 
done right.

Do you perhaps happen to have any insight to the original problem?

I thought the EODatabaseOperation might perhaps try to be smart and refuse to 
operate over another EC, without realising the another EC in fact is the 
current EC's SEC; but I guess in this case it would rather throw an exception 
instead of silently ignoring half of the changes :/

Also, I have checked the EODatabaseContext API just in case there might be 
either a overridable method to create those database operations, or callable 
one to order them, but so far, in vain: all relevant methods seem to be private 
(which, far as I understand Java, means they can be called — with some danger 
—, but can't be overridden); and the one method whose name seems interesting, 
i.e., “NSArray orderAdaptorOperations()”, has no argument, i.e., it does not 
seem to be possible to provide my own list of adaptor operations and ask the 
DBContext to order them.

Darn.

Well of course I can simply simulate what DBContext most probably does (does it 
indeed?), to order adaptor operations using 
“compareAdaptorOperation(EOAdaptorOperation other)”; but I somewhat fear there 
would be some subtle undocumented difference, which would raise its ugly head 
and bite me in tender parts the next month or the next year :/

Thanks and all the best,
OC

>> On Jan 12, 2020, at 7:00 AM, OCsite via Webobjects-dev 
>> mailto:webobjects-dev@lists.apple.com>> 
>> wrote:
>> 
>> P.S.
>> 
>>> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev 
>>> mailto:webobjects-dev@lists.apple.com>> 
>>> wrote:
>>> As for the fixing... well, I guess I can generate the proper AOs myself, 
>>> but the trick is, how do I order them? I would need to reuse the standard 
>>> default ordering which EODatabaseContext does normally; but it does not 
>>> seem to be accessible anyhow, or am I overlooking something of importance 
>>> here?
>> 
>> It looks like
>> 
>> ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
>> ...
>> class OCSDBOperation extends EODatabaseOperation { ... }
>> 
>> does not work :( Do I do something wrong, or it simply can't be overridden?
>> 
>> To be frank, I do not quite understand how the ERXPatcher (or, rather, 
>> _NSUtilities.setClassForName) magic actually works: should it work for any 
>> WO/EO class, or is there simply a dictionary somewhere inside the opaque 
>> Apple code, and it works only for classes which Apple explicitly addresses 
>> by some “Class clazz=dict[name]”, with no way to patch the others?
>> 
>> Thanks!
>> OC
>> 
>> ___
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com 
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com
>>  
>> <https://lists.apple.com/mailman/options/webobjects-dev/hill.chuck%40gmail.com>
>> 
>> This email sent to hill.ch...@gmail.com
> 

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: More SharedEC woes: relationships into SEC not saved?!?

2020-01-12 Thread OCsite via Webobjects-dev
P.S.

> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev 
>  wrote:
> As for the fixing... well, I guess I can generate the proper AOs myself, but 
> the trick is, how do I order them? I would need to reuse the standard default 
> ordering which EODatabaseContext does normally; but it does not seem to be 
> accessible anyhow, or am I overlooking something of importance here?

It looks like

ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
...
class OCSDBOperation extends EODatabaseOperation { ... }

does not work :( Do I do something wrong, or it simply can't be overridden?

To be frank, I do not quite understand how the ERXPatcher (or, rather, 
_NSUtilities.setClassForName) magic actually works: should it work for any 
WO/EO class, or is there simply a dictionary somewhere inside the opaque Apple 
code, and it works only for classes which Apple explicitly addresses by some 
“Class clazz=dict[name]”, with no way to patch the others?

Thanks!
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Re: More SharedEC woes: relationships into SEC not saved?!?

2020-01-12 Thread OCsite via Webobjects-dev
Hello,

I have pursued the problem and it seems to be somewhere at the 
EODatabaseOperation level. Implementing the 
databaseContextWillOrderAdaptorOperations delegate method and logging this:

===
NSArray databaseContextWillOrderAdaptorOperations(EODatabaseContext dbCtxt, 
NSArray databaseOps) {
databaseOps.each {
String op=... a switch to turn it.databaseOperator to a string ... 
incidentally, isn't there a system API for that?
println "-- $op on $it.object ..."
println " NR $it.newRow"
println " RD $it.rowDiffs"
println " CH $it.object.changesFromCommittedSnapshot"
println " AOs -> $it.adaptorOperations"
===

I get for the described case essentially this result:

===
-- UPDATE on  ...
 NR [a_id:132, b_id:]
 RD [a_id:132]
 CH [a:someObject, b:someSharedObject]
 AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator = 
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 132  
}; }]
===

which seems to be the root of the problem. I log CH to make sure the changes 
did not disappear magically: they are still known and all right, thus, the NR 
(and thus also RD and thus also AOs) are wrong.

Note that it does not seem the wrong NR is the only problem; I have tried to 
fix the thing programmatically like this:

===
NSMutableDictionary md=it.newRow.mutableClone()
b_it=it.object.changesFromCommittedSnapshot.b.rawPrimaryKey
println "... -> $md"
it.newRow=md
println "... NR $it.newRow"
println "... RD $it.rowDiffs"
println "... AOs -> $it.adaptorOperations"
===

and got proper RD as expected, but still wrong AOs, as not expected:

===
... -> [a_id:132, b_id:101]
... NR [a_id:132, b_id:101]
... RD [a_id:132, b_id:101]
 AOs -> [{_qualifier = "(uid = 1000190)"; _adaptorOperator = 
"EOAdaptorUpdateOperator"; _entity = "Foo"; _changedValues = {a_id = 132  
}; }]
===

Does anybody understand why this happens, and does anybody see how to fix it?

As for the fixing... well, I guess I can generate the proper AOs myself, but 
the trick is, how do I order them? I would need to reuse the standard default 
ordering which EODatabaseContext does normally; but it does not seem to be 
accessible anyhow, or am I overlooking something of importance here?

Thanks and all the best,
OC

> On 11 Jan 2020, at 3:28, OCsite via Webobjects-dev 
>  wrote:
> 
> Hi there,
> 
> this is weird. My EOs have some relationships into the SharedEC — of course, 
> one-way without an inverse; I understand that relationships to SEC are all 
> right, only those from it outside are forbidden. (Am I wrong perhaps? If 
> those relationships were set up in the database without SEC, it works 
> perfectly.)
> 
> Nevertheless, when I run with SEC, whatever I try, it seems these 
> relationships are — silently and without reporting any problem — not saved.
> 
> Say, I have an EO foo of entity Foo with two simple :1 relationships: a 
> (based on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a 
> shared-EC entity. Both are modelled the same way (simple join from the FK in 
> the source entity to the PK of the target entity). I set both of them, like 
> this:
> 
> ===
> ERXEC ec=
> Foo foo=new Foo()
> ec.insertObject(foo)
> assert ec==someObject.editingContext()
> foo.a=someObject
> assert ec.sharedEditingContext()==someSharedObject.editingContext()
> foo.b=someSharedObject
> assert foo.b==someSharedObject
> ec.saveChanges()
> ===
> 
> Now, changes are saved, no error is reported, new object is properly inserted 
> into the database
> - its a_id is filled by someObject's PK
> - whilst its b_id is filled by NSKeyValueCoding$Null!
> 
> Same happens when editing: the relationships to SEC when changed never seem 
> to save the appropriate FK value. It seems completely ignored by the saving 
> process:
> 
> ===
> assert 
> foo.editingContext().sharedEditingContext()==anotherSharedObject.editingContext()
> foo.b=anotherSharedObject
> assert foo.b==anotherSharedObject
> assert foo.committedSnapshotValueForKey('b')==NSKeyValueCoding$Null
> assert foo.changesFromCommittedSnapshot==[b: anotherSharedObject]
> foo.editingContext().saveChanges()
> assert foo.b==null
> ===
> 
> other changes of foo (if any) are saved all right, but its b_id never 
> changes. No error is reported.
> 
> Does this make any sense, is it perhaps an expected behaviour? As always, I 
> might be overlooking something of importance, but this feels completely wrong 
> to me

More SharedEC woes: relationships into SEC not saved?!?

2020-01-10 Thread OCsite via Webobjects-dev
Hi there,

this is weird. My EOs have some relationships into the SharedEC — of course, 
one-way without an inverse; I understand that relationships to SEC are all 
right, only those from it outside are forbidden. (Am I wrong perhaps? If those 
relationships were set up in the database without SEC, it works perfectly.)

Nevertheless, when I run with SEC, whatever I try, it seems these relationships 
are — silently and without reporting any problem — not saved.

Say, I have an EO foo of entity Foo with two simple :1 relationships: a (based 
on FK a_id) into a normal-EC entity, and b (based on FK b_id) into a shared-EC 
entity. Both are modelled the same way (simple join from the FK in the source 
entity to the PK of the target entity). I set both of them, like this:

===
ERXEC ec=
Foo foo=new Foo()
ec.insertObject(foo)
assert ec==someObject.editingContext()
foo.a=someObject
assert ec.sharedEditingContext()==someSharedObject.editingContext()
foo.b=someSharedObject
assert foo.b==someSharedObject
ec.saveChanges()
===

Now, changes are saved, no error is reported, new object is properly inserted 
into the database
- its a_id is filled by someObject's PK
- whilst its b_id is filled by NSKeyValueCoding$Null!

Same happens when editing: the relationships to SEC when changed never seem to 
save the appropriate FK value. It seems completely ignored by the saving 
process:

===
assert 
foo.editingContext().sharedEditingContext()==anotherSharedObject.editingContext()
foo.b=anotherSharedObject
assert foo.b==anotherSharedObject
assert foo.committedSnapshotValueForKey('b')==NSKeyValueCoding$Null
assert foo.changesFromCommittedSnapshot==[b: anotherSharedObject]
foo.editingContext().saveChanges()
assert foo.b==null
===

other changes of foo (if any) are saved all right, but its b_id never changes. 
No error is reported.

Does this make any sense, is it perhaps an expected behaviour? As always, I 
might be overlooking something of importance, but this feels completely wrong 
to me. Could it be caused by some bug at my side? If so, any idea where and how 
to hunt for it?

Thanks a lot for any insight,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com


Sorta solved: suspicious sessions and R/R loops created for a CSS font

2020-01-10 Thread OCsite via Webobjects-dev
Hugi,

thanks!

> On 10 Jan 2020, at 20:19, Hugi Thordarson  wrote:
> Well, WOStaticResourceRequestHandler doesn't really "create a 
> request/response loop". A request is is sent to the application, the 
> application will then look at the URL and determine from that what request 
> handler should handle the request. That handler then generates a response.

That's how I understand it. Furthermore, do please correct me if I am wrong, 
but I understand that the ComponentRequestHandler does that by running an R/R 
loop, whilst most other handlers do not.

> In this case WO has determined WOStaticResourceRequestHandler is your guy, 
> but I'm not sure why, because thi URL should really just throw an error 
> (which makes me think there's more going on here).

Here is begins to be interesting. Probably I do not understand the behaviour 
quite properly.

Far as I can say, all those request handlers are not documented anywhere (if 
there's a documentation for them, I'd be grateful for a link to it), but I have 
always thought that the WOStaticResourceRequestHandler is there just to handle 
fixed URIs like this one.

After all, my jQuery, referenced in the HTML header using



gets actually loaded — far as I can say —for a very similar URI  by this very 
handler, and it works all right, no extra R/R happens here:

===
WorkerThread6 WILLDISPATCH http://localhost:56005/cgi-bin/WebObjects/CEBOIS.woa/wo/9UuJz2GsVhmGAeV07uiU2g/2.0.0.9.1.1.1.0.3.1.1
 
],
 user-agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) 
AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15]} 
content-length=0 cookies=null userInfo={} storePageInBacktrackCache=true >) 
method=GET uri=/dms/js/jquery-3.1.0.min.js defaultFormValueEncoding=UTF-8 
formValueEncodingDetectionEnabled=NO formValueEncoding=UTF-8 formValues={} >
WorkerThread6 WILLGETHANDLER ''
WorkerThread6 DIDGETHANDLER ?NULL?
WorkerThread6 WILLGETHANDLER '_wr_'
WorkerThread6 DIDGETHANDLER '_wr_' -> class 
com.webobjects.appserver._private.WOStaticResourceRequestHandler
===

> Anyhow… Judging from your request logs, you're either running in direct 
> connect mode

Right, the logs came from my development machine which runs direct connect. I 
know it's a bit old-fashioned, but so far I did not bump into any problem which 
would cause me to switch (and I've checked the production server logs to make 
sure the bogus R/R's happen there just as well, i.e., they are not caused by 
direct connect, but by another quirk).

> ... So don't use absolute URLs like that.

So far, there was no problem with them for years and years, neither development 
nor deployment side. Perhaps we just got lucky so far.

> Chuck's initial comment was probably right on the money; the relative 
> references in your CSS-file weren't resolving correctly to a file. Start by 
> checking that. If you kept the directory structure provided by your designer 
> when copying in the CSS-files/template, it really should just work.

> Alternatively, you can change your CSS-files to reference full URLs (i.e. 
> including domain, or really; just the full resource URL you know works) when 
> referencing the resources in question.

Alas fear not, as I wrote

===
> On 10 Jan 2020, at 14:29, ocs@ocs  wrote:
> I have tried to change the URLs in the CSS file to absolute ones like this:
> ...
> src: url('/dms/css/font-awesome/fonts/fontawesome-webfont.eot?v=4.6.3');
> ...
> and the problem persists. It persists even if I use complete URLs incl. the 
> server, like “http://localhost:56005/dms/css/font-awesome 
> ...”, which I tried too.

===

> ... As always, It's kind of difficult to assist without knowing or seeing the 
> project or setup, but hopefully the suggestions help :).

Regardless above, strangely, they did: they led me to think about those URLs 
and, well, although I have abso-bloomin-lootely no idea of how the @font-face 
thing should work, those form elements and even one fragment looked darn 
suspicious. The refs are just to load the font file contents from the given 
URL, aren't they? In which case form does not make any sense far as I can say.

Anyway, removing them did help — the bogus R/Rs immediately disappeared!

But for one, the “fontawesome-webfont.woff2” for some godforsaken reason did 
generate still one — now just one instead of original 4 — bogus R/Rs. Here 
though I found I can remove the thing altogether and it still works (presumably 
all the comma-separated URIs in there just offer alternatives for different 
font formats not/supported by the browser).

So, it seems that the WOStaticResourceRequestHandler would create a bogus R/R 
loop if there is a form at the end of the URL; removing the form removes the 
R/R loop too.

That's not the whole story — there would be other conditions which cause the 
R/R loop to be run, which did happe

suspicious sessions and R/R loops created for a CSS font

2020-01-09 Thread OCsite via Webobjects-dev
Gentlemen,

my application does some R/R loops and creates some sessions/main components 
which I believe it should not.

Lately, from a webdesigner, I have got some improvements of the look of my 
application, which essentially looks like



in the html header. The CSS starts with

===
/*!
 *  Font Awesome 4.6.3 by @davegandy - http://fontawesome.io - @fontawesome
 *  License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT 
License)
 */@font-face {
font-family: 'FontAwesome';
src: url('../fonts/fontawesome-webfont.eot?v=4.6.3');
src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.6.3') 
format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff2?v=4.6.3') 
format('woff2'), url('../fonts/fontawesome-webfont.woff?v=4.6.3') 
format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.6.3') 
format('truetype'), 
url('../fonts/fontawesome-webfont.svg?v=4.6.3#fontawesomeregular') 
format('svg');
font-weight: normal;
font-style:normal
}
===

Then, things like



are used throughout the component templates, with the appropriate classes 
looking like

===
.fa {
display: inline-block;
font: normal normal normal 14px/1 FontAwesome;
font-size: inherit;
text-rendering: auto;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing:grayscale
}
.fa-plus:before {
content: "\f067"
}
===

It seems to render the characters all right, but the reason why I am writing is 
that as soon as the  thing is used in the page, I am getting VERY 
suspicious R/R loops and extra sessions. Namely, what I see is that

1. normal R/R loop for the standard URI "...myapp/wo/SID/COMPONENT" happens, 
uses the long-ago-created session for SID as it should, ends by 
application.sleep(). Precisely same as if there's no , so far so 
good.

But, if there _is_ an  thing in the page, I immediately and 
automatically (without doing anything in the browser) get another four R/R 
loops (far as I can say, served by the same thread as the first normal one); 
each of them creates a new session and a Main page (which is never shown 
anywhere), and if I log out its context().request() in the newly created 
session's awake(), it seems self-evident these R/R loops are created for the 
URIs from the CSS header, namely

2. ../fonts/fontawesome-webfont.woff2?v=4.6.3
3. ../fonts/fontawesome-webfont.woff?v=4.6.3
4. ../fonts/fontawesome-webfont.ttf?v=4.6.3
5. ../fonts/fontawesome-webfont.svg?v=4.6.3

(For some reason, for those .eot URIs this does not happen.)

Now, I understand that the fonts need to be loaded; nevertheless, it does not 
feel right that a full-fledged R/R loop, which creates a session and a Main 
page, is created and run for this.

Is that right? As always, I might be overlooking something of importance, but 
to me this feels wrong; there should be no need to create a full-fledged R/R 
for this, far as I understand. There are many other resources/CSSs/javascripts 
the application uses (incl. the very "font-awesome.min.css"), and none of them 
causes this; they all are loaded without R/R loops, without sessions, etc.

The designer knows sweet zilch of WebObjects and says if there's a problem at 
all, it's caused by my application around his perfect and flawless CSS. Well 
perhaps it is indeed; but I can't see the culprit.

Does anybody here understand the problem and can say how to fix it (or, at 
worst, that it is unfixable in principle and I have to bear with it)?

Thanks a lot,
OC

 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com