Happy to help! Sometimes it pays to be a dinosaur :)
Ken
> On Dec 11, 2013, at 12:05 PM, Alexis Tual wrote:
>
> Many thanks Ken, that was it !
> I've added all back-pointing relationships (no need to generate attributes
> for them) and prefetch works, even on the parent entity (A in my exampl
Many thanks Ken, that was it !
I've added all back-pointing relationships (no need to generate attributes
for them) and prefetch works, even on the parent entity (A in my example),
that's a great improvement !
Cheers,
Alex
2013/12/9 Alexis Tual
> Yes it's referencing A in my example. Do I hav
Yes it's referencing A in my example. Do I have to reference all
subentities of A ? I'll try tomorrow at the office.
Thanks
Alex
2013/12/9 Ken Anderson
> Is the back pointing relationship referencing the superclass? You need to
> create multiple relationships, specifically naming all the sub
Is the back pointing relationship referencing the superclass? You need to
create multiple relationships, specifically naming all the subclasses.
On Dec 9, 2013, at 5:41 PM, Alexis Tual wrote:
> Hi Ken,
>
> thanks for your suggestion, but I already have the backpointing
> relationship...
> I'
Hi Ken,
thanks for your suggestion, but I already have the backpointing
relationship...
I'll try to do a simple projet to isolate the issue.
Alex
2013/12/6 Ken Anderson
> In ancient times… (and I mean like, 15 years ago)
>
> A back pointing relationship from the subclasses of B to the abstra
gt; - Mail original -
> De: "Henrique Prange"
> À: webobjects-dev@lists.apple.com
> Cc: "Elizio Marcelino"
> Envoyé: Mercredi 4 Décembre 2013 08:42:09
> Objet: Re: Inheritance ERRest
>
> Hi all,
>
> We've found out this is a bug. The ERRe
In ancient times… (and I mean like, 15 years ago)
A back pointing relationship from the subclasses of B to the abstract A (where
the to-many relationship ‘toB' is) was necessary for all the plumbing to hook
things up when the EOs came back from the prefetch.
Ken
On Dec 5, 2013, at 3:08 PM, Ale
On 2013-12-05 12:08 PM, "Alexis Tual" wrote:
Hi,
I have 2 single table hierarchies :
- B1 inherits from B
- A1 inherits from A (abstract), A1 has a to-many relationship to B, let's call
it toBs
is it possible to prefetch this relationship ?
We can't manage to get it work, I'll paste the obscur
Beside running the ERRestRouteExample app to see if anything is broken, not
much other way to verify.
- Mail original -
De: "Henrique Prange"
À: webobjects-dev@lists.apple.com
Cc: "Elizio Marcelino"
Envoyé: Mercredi 4 Décembre 2013 08:42:09
Objet: Re: Inherit
Hi all,
We've found out this is a bug. The ERRestRequestNode ignores the type field
when creating objects for toOne and toMany relationships. We're going to create
a pull request to fix this problem soon.
BTW, is there a way to verify we didn't introduce a bug in ERRest while trying
to fix ano
Thanks Pascal,
Unfortunately still no luck. If I add in an id field I get:
IllegalStateException: The object with globalID _EOIntegralKeyGlobalID[EntityA
(java.lang.Integer)0] could not be found in the database. This could be result
of a referential integrity problem with the database. An empty
By passing the 'type' argument, it should work automatically. But I see that
you don't pass any 'id' (primary keys) for Entity C and Entity B, if you wish
to use existing Entity C and B objects when you create a Entity Z object, you
need to pass the id.
> Hi,
>
> I have a hierarchy of objects
would bite me later.
>
> EOF is going to explode!
>
>
> Chuck
>
>
>> --- On Sat, 11/19/11, Paul Yu wrote:
>>
>>> From: Paul Yu
>>> Subject: Re: inheritance (EO Subclass) ?
>>> To: "Theodore Petrosky"
>>> Cc: web
Chuck
> --- On Sat, 11/19/11, Paul Yu wrote:
>
>> From: Paul Yu
>> Subject: Re: inheritance (EO Subclass) ?
>> To: "Theodore Petrosky"
>> Cc: webobjects-dev@lists.apple.com
>> Date: Saturday, November 19, 2011, 9:42 AM
>> Ted
>>
>
this approach was 'good' or was I boxing myself into a corner that would
bite me later.
Ted
--- On Sat, 11/19/11, Paul Yu wrote:
> From: Paul Yu
> Subject: Re: inheritance (EO Subclass) ?
> To: "Theodore Petrosky"
> Cc: webobjects-dev@lists.apple.com
> Da
Ted
I'm no expert on inheritance, but typically the setup should be
Contact (Parent class) with a idContactType, marked as Abstract
ContactType (1, Employee; 2, Vendor; 3, Media)
Employee (Parent = Contact, Qualifier idContactType = 1)
VendorContact (Parent = Contact, Qualifier idContactType = 2
Hi Ted,
On Jul 28, 2010, at 6:04 AM, Theodore Petrosky wrote:
> 2. Migrations don't support inheritance yet...
Entity Modeler's migration generation may take it into account if you were
generating both the superclass and the subclass at the same time, but even if
it doesn't, just modify the co
For posterity:
- if you get this error then yes there's a problem with your model :-)
- For me, changing the restricting qualifiers to reference a character flag
instead of a boolean seems to have fixed this issue. So that would be one
example of what not to do.
- As Chuck said in his last, it
On Jan 4, 2010, at 5:06 PM, Tim Worman wrote:
On Jan 4, 2010, at 4:39 PM, Chuck Hill wrote:
On Jan 4, 2010, at 4:30 PM, Tim Worman wrote:
On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
On Jan
On Jan 4, 2010, at 5:06 PM, Tim Worman wrote:
> On Jan 4, 2010, at 4:39 PM, Chuck Hill wrote:
>
>> On Jan 4, 2010, at 4:30 PM, Tim Worman wrote:
>>> On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
> On Jan 4, 2010, at 3:27 PM, Chuck Hill
On Jan 4, 2010, at 4:39 PM, Chuck Hill wrote:
> On Jan 4, 2010, at 4:30 PM, Tim Worman wrote:
>> On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
>>> On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
> On Jan 4, 2010, at 3:13 PM, Tim Worman wro
On Jan 4, 2010, at 4:30 PM, Tim Worman wrote:
On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
Is it pretty much a certainty that the error I'm experien
> Kevin
>
>> -Original Message-
>> From:
>> webobjects-dev-bounces+kevin.ren=anz@lists.apple.com
>> [mailto:webobjects-dev-bounces+kevin.ren=anz@lists.apple.c
>> om] On Behalf Of Tim Worman
>> Sent: Tuesday, 5 January 2010 12:43 p.m.
>
On Jan 4, 2010, at 4:00 PM, David Avendasora wrote:
>
> On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
>
>> On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
>>
>>>
>>> On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
>>>
Is it pretty much a certainty that the error I'm experiencing is caused by
On Jan 4, 2010, at 3:42 PM, Tim Worman wrote:
On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
Is it pretty much a certainty that the error I'm experiencing is
caused by a problem in my models? This problem is a show stopper
for me right now. J
Of Tim Worman
> Sent: Tuesday, 5 January 2010 12:43 p.m.
> To: Chuck Hill
> Cc: WebObjects-Dev List
> Subject: Re: inheritance problem...
>
> On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
>
> >
> > On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
>
On Jan 4, 2010, at 6:42 PM, Tim Worman wrote:
> On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
>
>>
>> On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
>>
>>> Is it pretty much a certainty that the error I'm experiencing is caused by
>>> a problem in my models? This problem is a show stopper for
On Jan 4, 2010, at 3:27 PM, Chuck Hill wrote:
>
> On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
>
>> Is it pretty much a certainty that the error I'm experiencing is caused by a
>> problem in my models? This problem is a show stopper for me right now. Just
>> for refresher, the error is:
>>
>
On Jan 4, 2010, at 3:13 PM, Tim Worman wrote:
Is it pretty much a certainty that the error I'm experiencing is
caused by a problem in my models? This problem is a show stopper for
me right now. Just for refresher, the error is:
Error: java.lang.IllegalStateException: The object with global
Is it pretty much a certainty that the error I'm experiencing is caused by a
problem in my models? This problem is a show stopper for me right now. Just for
refresher, the error is:
Error: java.lang.IllegalStateException: The object with globalID
_EOIntegralKeyGlobalID[Timesheet (java.lang.Lon
Tim Worman
UCLA GSE&IS
On Dec 30, 2009, at 3:18 AM, David Avendasora wrote:
>
> On Dec 29, 2009, at 9:46 PM, Tim Worman wrote:
>
>> OK, so, I've reviewed all the prototypes in use, data types, etc. I did find
>> some areas where my prototypes were messed up so it was worth it to go
>> thro
On Dec 30, 2009, at 3:21 PM, Tim Worman wrote:
> I'm using Wonder and have my connection properties set up in Properties.
> Originally I was using separate Properties/Model entries for each model. But
> now since they're using the same database I'm just using dbConnect*Global
> connection prop
On Dec 30, 2009, at 3:18 AM, David Avendasora wrote:
>
> On Dec 29, 2009, at 9:46 PM, Tim Worman wrote:
>
>> OK, so, I've reviewed all the prototypes in use, data types, etc. I did find
>> some areas where my prototypes were messed up so it was worth it to go
>> through it all. The fk and pk b
On Dec 29, 2009, at 9:46 PM, Tim Worman wrote:
> OK, so, I've reviewed all the prototypes in use, data types, etc. I did find
> some areas where my prototypes were messed up so it was worth it to go
> through it all. The fk and pk both are long values.
>
> But I'm still getting the same error.
OK, so, I've reviewed all the prototypes in use, data types, etc. I did find
some areas where my prototypes were messed up so it was worth it to go through
it all. The fk and pk both are long values.
But I'm still getting the same error. This solution also doesn't cross
databases. It does cross
Check cross database issues and also name sure the types on your pk
and fk match ... I notice that says your fk is a long, make sure that
matches the pk of the destination entity.
Sent from my iPhone
On Dec 28, 2009, at 7:33 PM, "Tim Worman" wrote:
...or wondering if I've modeled something
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
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
Something that does it all in one place (root of the hierarchy)...
Should take care of the problem with intermediate classes. It also
fails quickly, as a reminder if one adds new subclasses to the
hierarchy, but forgets to deal with their type identifiers.
private static final Map mdSubtype
On May 9, 2008, at 10:08 AM, Florijan Stamenkovic wrote:
I dealt with this issue by adding the following code in my abstract
root... It avoids the pitfall you mention. One must be careful
however that *every* subclass implements _getType() because the
compiler will not complain as long as
I dealt with this issue by adding the following code in my abstract
root... It avoids the pitfall you mention. One must be careful
however that *every* subclass implements _getType() because the
compiler will not complain as long as any of the super-classes have
this.
public void awakeFro
Oh, and I almost forgot, if you have multiple levels of inheritance,
your awakeFromInsertion setting the class type is a little more tricky
because the first thing you do in awakeFromInsertion is to call
super.awakeFromInsertion. The problem is that if the class you are
working on is more t
Kieran,
Thanks for the explanation. I understand what you mean now... It
definitely sounds good, though I have still to figure out exactly how
I would apply this to my situation. Since among the inheritance types
EOF provides single-table seems most applicable to my situation, I
might swi
On May 8, 2008, at 10:26 AM, Hugi Þórðarson wrote:
How will it work for Wonder's "Partial" Entities that are part of
a Vertical Inheritance structure on a full moon with Pluto in the
third house?
Yes.
I totally disagree with that! Totally!
Well, of course it is all different in the pr
How will it work for Wonder's "Partial" Entities that are part of a
Vertical Inheritance structure on a full moon with Pluto in the third
house?
On May 8, 2008, at 12:51 PM, Chuck Hill wrote:
On May 8, 2008, at 7:14 AM, Florijan Stamenkovic wrote:
Besides the question below, I came up wit
On May 8, 2008, at 11:29 AM, Florijan Stamenkovic wrote:
On May 08, 2008, at 10:47, Kieran Kelleher wrote:
15 entities with 30 max records per entity = max 450
records. .. even with 100 attributes this is probably trivial
data size, so I would not go out of my way to avoid Single Tabl
How will it work for Wonder's "Partial" Entities that are part of a
Vertical Inheritance structure on a full moon with Pluto in the
third house?
Yes.
I totally disagree with that! Totally!
- hugi
// Hugi Thordarson
// http://hugi.karlmenn.is/
_
On May 08, 2008, at 12:51, Chuck Hill wrote:
Besides the question below, I came up with another scenario
today... While it is true that performance should not be an issue
with the records in the inheritance tree, what about
relationships? I will have potentially thousands of records that
On May 8, 2008, at 10:08 AM, David Avendasora wrote:
How will it work for Wonder's "Partial" Entities that are part of a
Vertical Inheritance structure on a full moon with Pluto in the
third house?
Yes.
Chuck
On May 8, 2008, at 12:51 PM, Chuck Hill wrote:
On May 8, 2008, at 7:14 AM
On May 8, 2008, at 7:14 AM, Florijan Stamenkovic wrote:
Besides the question below, I came up with another scenario today...
While it is true that performance should not be an issue with the
records in the inheritance tree, what about relationships? I will
have potentially thousands of rec
On May 8, 2008, at 8:27 AM, Mike Schrag wrote:
Just to get it straight, you keep the not-null constraints in the
model, but skip them in the db? Can't find docs on this...
Yes. Welcome to the awesome docs on inheritance in EOF. They don't
document a LOT of stuff. Just try to understand t
I did get that... Apple's docs explain it clearly... What I don't
get is why they use the integers 2 and 9 in a three entity setup
(abstract root + 2 concrete) as qualifier values...
Totally arbitrary. I would assume they chose 2 and 9 to make it
explicitly appear arbitrary.
ms
__
Oh, and BTW if this is Java Client you need to set the restricting
qualifier (or type) on both the client AND the server, AND surround
the setter with a check for null first, otherwise it causes all sorts
of weird unrelated errors when you try to delete an instance of the
subclass. This dro
On May 8, 2008, at 7:46 AM, Ken Anderson wrote:
OK - I'm thinking it's time for me to look at WOnder... :)
M, might be a few years overdue on that one. ;-)
On May 8, 2008, at 10:43 AM, Mike Schrag wrote:
There are a number of issues with prefetching relationships that
relate back to
On May 08, 2008, at 11:27, Mike Schrag wrote:
All that matters is that you have some restricting qualifier that
specifies how to differentiate the two entities (the value doesn't
matter, but you do need some attribute that specifies which one is
a SubEntity1 and which one is a SubEntity2).
On May 08, 2008, at 10:47, Kieran Kelleher wrote:
15 entities with 30 max records per entity = max 450
records. .. even with 100 attributes this is probably trivial
data size, so I would not go out of my way to avoid Single Table
inheritance for the sake of avoiding a lot of null field
There are a number of issues with prefetching relationships that
relate back to an abstract entity.
Yay... Is this true also of single-table inheritance?
Yes.
Just to get it straight, you keep the not-null constraints in the
model, but skip them in the db? Can't find docs on this...
Yes.
On May 08, 2008, at 10:28, Ken Anderson wrote:
There are a number of issues with prefetching relationships that
relate back to an abstract entity.
Yay... Is this true also of single-table inheritance?
I haven't tried this in a VERY long time, so if I were you, I'd
experiment with this b
OK - I'm thinking it's time for me to look at WOnder... :)
On May 8, 2008, at 10:43 AM, Mike Schrag wrote:
There are a number of issues with prefetching relationships that
relate back to an abstract entity. I haven't tried this in a VERY
long time, so if I were you, I'd experiment with this
15 entities with 30 max records per entity = max 450 records. ..
even with 100 attributes this is probably trivial data size, so I
would not go out of my way to avoid Single Table inheritance for the
sake of avoiding a lot of null fields in the database.
If it was me, for such a complex
There are a number of issues with prefetching relationships that
relate back to an abstract entity. I haven't tried this in a VERY
long time, so if I were you, I'd experiment with this before moving
ahead with a concrete plan.
Bottom line, if you don't need other people to access these tab
There are a number of issues with prefetching relationships that
relate back to an abstract entity. I haven't tried this in a VERY
long time, so if I were you, I'd experiment with this before moving
ahead with a concrete plan.
Bottom line, if you don't need other people to access these tab
There are a number of issues with prefetching relationships that
relate back to an abstract entity. I haven't tried this in a VERY
long time, so if I were you, I'd experiment with this before moving
ahead with a concrete plan.
Bottom line, if you don't need other people to access these tab
Ken,
Yeah, I was just thinking about that (see my post from a minute
ago)... Comments on potential performance issues?
F
On May 08, 2008, at 10:04, Ken Anderson wrote:
If you're only going to fetch on the leaf entities, I would favor
horizontal just from an organizational point of view.
Besides the question below, I came up with another scenario today...
While it is true that performance should not be an issue with the
records in the inheritance tree, what about relationships? I will
have potentially thousands of records that have two mandatory
relationships to the leaf no
If you're only going to fetch on the leaf entities, I would favor
horizontal just from an organizational point of view. Remember
though, if you have relationships to the root entity (like the inverse
of a to-many relationship that all subentities have), you're still
going to have extra fet
On May 7, 2008, at 7:55 PM, Mike Schrag wrote:
Vertical or horizontal? With vertical this will still select on
the root, won't it?
That's actually a good question. It will have to select against
the root, obviously, to pick up those attributes, but I don't
think it then calls all the ot
Vertical or horizontal? With vertical this will still select on
the root, won't it?
That's actually a good question. It will have to select against the
root, obviously, to pick up those attributes, but I don't think it
then calls all the other siblings if you call against a leaf node,
bu
Thanks everyone from preventing me to learn the hard way...
Apparently my choices are single-table or horizontal.
A question: assuming I intend to perform individual fetches for each
entity anyway, that there will be no direct fetching on the root
entity, and that there will be maybe 100 re
On 08/05/2008, at 6:27 AM, Chuck Hill wrote:
On May 7, 2008, at 1:14 PM, Robert Walker wrote:
The only time vertical inheritance makes sense if when you always
fetch against leaf nodes of the inheritance tree and only if the
inheritance tree is very shallow. Take that to mean one level deep
I believe that it does select against all the other nodes as well. I
remember seeing a lot of DB traffic with Vertical and wondering why it
would need to select against the tables for the other subclasses.
The only fault I can see with Single Table is that it can cause
constraint difficulti
1 - 100 of 119 matches
Mail list logo
