On 2015-02-21, 11:17 AM, "OC" wrote:
Chuck,
On 21. 2. 2015, at 20:09, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
I think it is a fair expectation that EOF may not properly support optimistic
pessimistic, I guess?
Cough. Yes.
locking. I am not even sure how to set it up properly. Th
Chuck,
On 21. 2. 2015, at 20:09, Chuck Hill wrote:
> I think it is a fair expectation that EOF may not properly support optimistic
pessimistic, I guess?
> locking. I am not even sure how to set it up properly. There are some
> methods on EOEditingContext and EODatabaseContext, and one the
>
I think it is a fair expectation that EOF may not properly support optimistic
locking. I am not even sure how to set it up properly. There are some methods
on EOEditingContext and EODatabaseContext, and one the EODatabaseContext
Delegate.
Chuck
On 2015-02-21, 3:42 AM, "OC" wrote:
Anyway, ba
I don’t know, I suggest asking on the FrontBase developers list.
On 2015-02-21, 2:55 AM, "OC" wrote:
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
One way would be to twist the DB to do the complete restraint to me, something
like to a pseudo-code “inserted_r
Hello there,
after having played for a time with constraints, I have decided to use a
trigger instead -- main reason is that I really want the validation performed
on INSERT only; a constraint might get evaluated in other occassions, too.
Nevertheless, I can't find a decent way of doing that in
Anyway, back to the original question --
On 20. 2. 2015, at 18:27, OC wrote:
>>> Actually _this_ should not be weird, this should be quite a normal code;
>>> the only requirement is that check-and-save, i.e., conceptually,
>>>
>>> ===
>>> if (TEST(eo.someRelationship().someAttribute(),newAttrib
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill wrote:
>> One way would be to twist the DB to do the complete restraint to me,
>> something like to a pseudo-code “inserted_row.attr>=MAX(SELECT attr FROM
>> this_table WHERE another_attr.isValid) AND couple more similar conditions”
>> -- frankly I
On 2015-02-20, 12:30 PM, "Ramsey Gurley" wrote:
On Feb 20, 2015, at 12:09 PM, OC mailto:o...@ocs.cz>> wrote:
it must pass a slightly more complex test than uniqueness:
- when inserted into PRICE_OFFERS table,
- the newly inserted object must have value in column PRICE, which is higher,
- than
On Feb 20, 2015, at 12:09 PM, OC wrote:
> it must pass a slightly more complex test than uniqueness:
>
> - when inserted into PRICE_OFFERS table,
> - the newly inserted object must have value in column PRICE, which is higher,
> - than any (max) of the already existing objects in that table, whi
Chuck,
On 20. 2. 2015, at 19:37, Chuck Hill wrote:
>> Actually _this_ should not be weird, this should be quite a normal code; the
>> only requirement is that check-and-save, i.e., conceptually,
>> === [1]
>> if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
>>def
>> new
On 2015-02-20, 9:27 AM, "OC" wrote:
Chuck,
Actually _this_ should not be weird, this should be quite a normal code; the
only requirement is that check-and-save, i.e., conceptually,
===
if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
def
new=EOUtilities.createAndInsertI
Ramsey,
On 20. 2. 2015, at 18:06, Ramsey Gurley wrote:
>> On 19. 2. 2015, at 19:15, Ramsey Gurley wrote:
>>> You do a lot of weird stuff :)
>> I am not using Eclipse anymore
> I stand by my original statement :D
:)
Anyway, as always, YMMV, but I found Eclipse next-to-unusable myself.
>> -- ca
Chuck,
>> Actually _this_ should not be weird, this should be quite a normal code; the
>> only requirement is that check-and-save, i.e., conceptually,
>>
>> ===
>> if (TEST(eo.someRelationship().someAttribute(),newAttributeValue)) {
>> def
>> new=EOUtilities.createAndInsertInstance(eo.editing
On Feb 20, 2015, at 4:52 AM, OC wrote:
> Ramsey,
>
> On 19. 2. 2015, at 19:15, Ramsey Gurley wrote:
>> You do a lot of weird stuff :)
>
> I am not using Eclipse anymore
I stand by my original statement :D
> -- can't speak for other platforms, but on Mac, I have never seen a worse IDE.
I’ve
Hi,
On 2015-02-20, 3:52 AM, "OC" wrote:
Ramsey,
On 19. 2. 2015, at 19:15, Ramsey Gurley
mailto:rgur...@smarthealth.com>> wrote:
You do a lot of weird stuff :)
Actually _this_ should not be weird, this should be quite a normal code; the
only requirement is that check-and-save, i.e., conceptual
On 20. 2. 2015, at 12:52, OC wrote:
> (Hmmm... now it occurred to me, perhaps I might set up an UNIQUE db
> restraint? That would probably simplify the code mightily, _and_ work for
> multi-instance case just as well...)
Hm, I need a holiday. _Now_ I have recalled that I have considered this
Ramsey,
On 19. 2. 2015, at 19:15, Ramsey Gurley wrote:
> You do a lot of weird stuff :)
Actually _this_ should not be weird, this should be quite a normal code; the
only requirement is that check-and-save, i.e., conceptually,
===
if (eo.someRelationship().someAttribute() Have you installed jad
You do a lot of weird stuff :) Have you installed jadclipse yet?
https://wiki.wocommunity.org/display/documentation/Useful+Eclipse+Plugins
You can probably answer a lot of your questions just looking at the source.
If I had this problem, I’d probably first try providing my own EC subclass
thro
Hello there,
occassionally, an object gets deleted which should not be. Now, just before
"ec.saveChanges()" I am logging out
===
lognow "saving INS:$ec.insertedObjects.count
UPD:$ec.updatedObjects.count DEL:$ec.deletedObjects.count"
===
and in my "databaseContextWillPerformAdaptorO
19 matches
Mail list logo
