On Aug 10, 2008, at 5:14 PM, Guido Neitzer wrote:
And in all my testing in the last days I cleaned all that stuff but
missed the password somehow ...
Damn. I should sleep more. Or drink more coffee. Or both.
Dunno about coffee, but sufficient beer will help you sleep more. :-P
--
Chu
On 10.08.2008, at 15:35, Chuck Hill wrote:
I didn't list it this time, though I should have .. I completely
forgot about this crazy problem. We should probably put some
checks in Wonder for common types of errors (connection dictionary
is CLOSE but not EXACT).
Maybe anything where the JD
On Aug 10, 2008, at 1:49 PM, Mike Schrag wrote:
I am pretty sure that both Mike and I told you to check this.
I didn't list it this time, though I should have .. I completely
forgot about this crazy problem. We should probably put some checks
in Wonder for common types of errors (connectio
I am pretty sure that both Mike and I told you to check this.
I didn't list it this time, though I should have .. I completely
forgot about this crazy problem. We should probably put some checks
in Wonder for common types of errors (connection dictionary is CLOSE
but not EXACT).
ms
_
On 10.08.2008, at 14:35, Chuck Hill wrote:
I am pretty sure that both Mike and I told you to check this. If
the connection dictionaries are not equals(), then EOF considers
them to point to different databases. So "
_EOIntegralKeyGlobalID[Person (java.lang.Long)3049] could not be
found
On Aug 10, 2008, at 1:22 PM, Guido Neitzer wrote:
So, something VERY weird:
I have nailed it down to one thing, and I have no idea why or how
this could cause the problems I was seeing:
Upon closer inspection of my models and why they weren't working, I
found an entry in the connection d
So, something VERY weird:
I have nailed it down to one thing, and I have no idea why or how this
could cause the problems I was seeing:
Upon closer inspection of my models and why they weren't working, I
found an entry in the connection dictionary:
password = "";
which was not present
On 09.08.2008, at 13:33, Mike Schrag wrote:
Mike, don't you see similar things with ERAttachment as David? Or
do you also relate to the specific subclass (that worked for me)?
I've never had this happen ... Just lucky, maybe?
Maybe. Tonight I'll have some time to create a test case with a be
Mike, don't you see similar things with ERAttachment as David? Or do
you also relate to the specific subclass (that worked for me)?
I've never had this happen ... Just lucky, maybe?
ms
___
Do not post admin requests to the list. They will be ignored.
Damn. I have it working. When I copied everything into one model, it
works.
Now I need to create a test case I can make a bug report with. Grmbl.
As if I hadn't wasted enough time with that shit.
Mike, don't you see similar things with ERAttachment as David? Or do
you also relate to the s
On 09/08/2008, at 1:14 PM, Mike Schrag wrote:
Where can I read up about this one?
Well, right here, my good man! I've always thought that making me
manually set the values of the attributes of my restricting
qualifier when I insert a new instance into an EC was stupid -- the
framework sho
Where can I read up about this one?
Well, right here, my good man! I've always thought that making me
manually set the values of the attributes of my restricting qualifier
when I insert a new instance into an EC was stupid -- the framework
should do that for me.
er.extensions.ERXEnterpris
On 09/08/2008, at 9:53 AM, Guido Neitzer wrote:
On 08.08.2008, at 15:11, Chuck Hill wrote:
Hmmm. Back to the old application, FETCHING works now. Resolving a
relationship to an object that was NOT cached earlier, crashes.
When I do a fetch, the relationship is resolved just fine when the
On 09/08/2008, at 3:11 AM, Mike Schrag wrote:
Chuck and I are jibber-jabbering on aim ... Random things to look at
(that I have no idea if they can happen or what they might cause):
* triple check that all your restricting qualifiers are set
* check that the restricting qualifier on your base
On 8-Aug-08, at 7:53 PM, Guido Neitzer wrote:
On 08.08.2008, at 15:11, Chuck Hill wrote:
Hmmm. Back to the old application, FETCHING works now. Resolving a
relationship to an object that was NOT cached earlier, crashes.
When I do a fetch, the relationship is resolved just fine when the
o
On 08.08.2008, at 00:38, Lachlan Deck wrote:
For the the relationship from 'some other object' to Person - is the
source object also an inherited object?
Not always.
Do you have a restricting qualifier?
Yes.
I've seen problems going from an inherited record to another
inherited record
On 08.08.2008, at 15:11, Chuck Hill wrote:
Hmmm. Back to the old application, FETCHING works now. Resolving a
relationship to an object that was NOT cached earlier, crashes.
When I do a fetch, the relationship is resolved just fine when the
object the relation is pointing to was fetched bef
On Aug 8, 2008, at 1:46 PM, Guido Neitzer wrote:
Hmmm. Back to the old application, FETCHING works now. Resolving a
relationship to an object that was NOT cached earlier, crashes.
When I do a fetch, the relationship is resolved just fine when the
object the relation is pointing to was fetc
Hmmm. Back to the old application, FETCHING works now. Resolving a
relationship to an object that was NOT cached earlier, crashes.
When I do a fetch, the relationship is resolved just fine when the
object the relation is pointing to was fetched before. But it stops
working as soon as the ti
On Aug 8, 2008, at 11:31 AM, Guido Neitzer wrote:
Update:
I have copied the affected models to a test app, deleted all other
entities and all relationships and there it works fine. WTF???
WTF Indeed!
More digging ...
Need back hoe?
Chuck
On 08.08.2008, at 12:15, Guido Neitzer wro
Update:
I have copied the affected models to a test app, deleted all other
entities and all relationships and there it works fine. WTF???
More digging ...
cug
On 08.08.2008, at 12:15, Guido Neitzer wrote:
On 08.08.2008, at 11:11, Mike Schrag wrote:
* triple check that all your restric
On 08.08.2008, at 10:59, Mike Schrag wrote:
That looks wrong. That should be the base class Person:
_EOIntegralKeyGlobalID[Person (java.lang.Long)10049]
Are you by any chance batch fetching in any of these tests? I did
make that change to Wonder's batch fetching to fix some inheritance
re
On 08.08.2008, at 11:11, Mike Schrag wrote:
* triple check that all your restricting qualifiers are set
Done. Seems all correct. That was my first thought.
* check that the restricting qualifier on your base class is set if
it's not abstract
It was not set, but the entity is abstract. To
Chuck and I are jibber-jabbering on aim ... Random things to look at
(that I have no idea if they can happen or what they might cause):
* triple check that all your restricting qualifiers are set
* check that the restricting qualifier on your base class is set if
it's not abstract
* check tha
That looks wrong. That should be the base class Person:
_EOIntegralKeyGlobalID[Person (java.lang.Long)10049]
Be careful, because this changes depending on where you refer to
it ... Prefetch, it's referred to as "Person" but post fetch, I think
it would be "EventsUser". There's some crazy st
That looks wrong. That should be the base class Person:
_EOIntegralKeyGlobalID[Person (java.lang.Long)10049]
Are you by any chance batch fetching in any of these tests? I did
make that change to Wonder's batch fetching to fix some inheritance
related problems (that maybe are related if you'
On Aug 8, 2008, at 9:36 AM, Guido Neitzer wrote:
On 08.08.2008, at 10:27, Chuck Hill wrote:
SELECT FROM contacts t0 WHERE
(t0.inheritance_type = 'BaseUser' OR t0.inheritance_type =
'EventsUser')
Isn't AppUser a subclass of BaseUser too? Where is the qualifier
for that?
That was onl
On 08.08.2008, at 10:27, Chuck Hill wrote:
SELECT FROM contacts t0 WHERE (t0.inheritance_type
= 'BaseUser' OR t0.inheritance_type = 'EventsUser')
Isn't AppUser a subclass of BaseUser too? Where is the qualifier
for that?
That was only my example. EventsUser is the actual class in that c
On Aug 8, 2008, at 9:22 AM, Guido Neitzer wrote:
On 08.08.2008, at 06:31, Guido Neitzer wrote:
But I think, there must be something funky with my models from the
refactoring. Right now, I can't even do a
NSArray result = Person.fetchAllPersons(editingContext, null);
It craps out with a si
On 08.08.2008, at 06:31, Guido Neitzer wrote:
But I think, there must be something funky with my models from the
refactoring. Right now, I can't even do a
NSArray result = Person.fetchAllPersons(editingContext, null);
It craps out with a similar illegal state exception.
Something is really
On 08.08.2008, at 00:38, Lachlan Deck wrote:
What type of inheritance? ST, H, VI.
Single Table.
For the the relationship from 'some other object' to Person - is the
source object also an inherited object?
Sometimes. Not necessarily.
Do you have a restricting qualifier?
Sure, I do.
S
On 08/08/2008, at 3:05 PM, Guido Neitzer wrote:
I'm running into a weird issue here and was thinking that this was
supposed to work.
In my model I have a AppUser entity which is a subclass of Person.
Now, if I have a relationship on some other object, lets say
"createdBy", and this points
Hi.
I'm running into a weird issue here and was thinking that this was
supposed to work.
In my model I have a AppUser entity which is a subclass of Person.
Now, if I have a relationship on some other object, lets say
"createdBy", and this points to the Person, it doesn't work when it is
33 matches
Mail list logo
