I mean:
Rather than saying this.getToMany() you can say EOFetchSpecification
(other, inverseToOne = this, null)
public static String
inverseRelationshipNameForRelationshipNameAndEntityName(
String relationshipName,
String entityName)
{
He means, rather than have a to-many relationship, like this:
A <-->> B
just have this:
A <-- B
Then when you want a certain subset of B, you can just do a fetch,
where B.A == the A you want, plus whatever else you want to filter on.
Ken
On Aug 16, 2007, at 5:00 PM, Paolo Sommaruga wrote:
Hi Pierre,
please,
Il giorno 16/ago/07, alle ore 19:18, Pierre Bernard ha scritto:
[...]
- just fetch required object regarding mentioned relationship as
just one
of attributes involved
A to-many is always the inverse of a to-one. You could qualify
objects using that to-one.
how one c
On Aug 16, 2007, at 11:40 AM, Steven Mark McCraw wrote:
Hi Pierre,
Can you elaborate on stale cache notification a bit, or else point
us to some documentation on it?
He means the EOObjectStore ObjectsChangedInStoreNotification. It is
up to you to interpret it.
Chuck
--
Practical
Hi Pierre,
Can you elaborate on stale cache notification a bit, or else point us
to some documentation on it?
Thanks,
Mark
You can listen to EOF notifications to see when your cache goes stale.
Pierre
___
Do not post admin requests to the list
Hi!
I have a to-many relationship, which points to rather large (about
100)
heap of objects.
100 is by no account a large number.
- cycle through array (which I get from relationship attribute),
checking
if attributes match
Kinda OK.
- construct EOQualifier and filter the array with
ditto for me. My early code is littered with tons of complex data
structures (dictionaries, arrays of arrays, lists, etc) created with
the intent of diminishing performance overhead. I have come to
believe that the best strategy you can take for something like this
is just to build it the
When I first started with WebObjects I was very worried about all the
overhead
of creating EOs, etc.
Well like some said here,, build it the easy way using WO and see if
you really
need to optimize. I use filtered arrays on relationships all the time
and it works
really well. I easily have
Hi!
On 2007/08/16, at 05:12, Gennady Kushnir wrote:
Only for that HUUGE arrays? I thowght, that caching of objects,
that EOF
do shoud significally speed up fetches... Will it do real database
roundtrip for fetching an object that's already cached in memory?
(I know
it is, as it is in that
On Aug 15, 2007, at 9:12 PM, Gennady Kushnir wrote:
With a hundred objects, that is quite okay. If you have to do it
multiple times, it might be an idea to convert it into a dictionary
and base the keys on the attributes you're looking for - if that is
doable. You haven't given enough informa
> With a hundred objects, that is quite okay. If you have to do it
> multiple times, it might be an idea to convert it into a dictionary
> and base the keys on the attributes you're looking for - if that is
> doable. You haven't given enough information here.
In fact, building a dictionary - it is
On 15.08.2007, at 17:25, Gennady Kushnir wrote:
- cycle through array (which I get from relationship attribute),
checking
if attributes match
With a hundred objects, that is quite okay. If you have to do it
multiple times, it might be an idea to convert it into a dictionary
and base the
Hi!
On 2007/08/16, at 00:25, Gennady Kushnir wrote:
- cycle through array (which I get from relationship attribute),
checking
if attributes match
Being a 100 elements array, I guess that's doable. CPUs are
screaming fast today, so even if you have to look-up the entire array
100 times
Hello, List
It is not an unresolvable problem. However I just want to perform tasks in
the most efficient way.
I have a to-many relationship, which points to rather large (about 100)
heap of objects.
I need to get one of these objects - which one depends on some other
attributes of one (or get nu
14 matches
Mail list logo
