Yeah, I started thinking about that ...
there is not a lot of data but I'll probably use a different solution.
Johnny
On Jan 15, 2010, at 5:55 PM, Mike Schrag wrote:
> this is REALLY non-optimal fetching here, but if it works for you, cool ...
>
> ms
>
> On Jan 15, 2010, at 10:53 PM, Johnny
Well at least there is a good reason I didn't find it.
After thinking about the query as SQL I decided to just use the "in" qualifier.
i.e. Artist.fetchMG_Artists(ec(),
Artist.ARTWORKS.in(Artwork.fetchAllMG_Artworks(ec())), so);
Thanks for the help.
Johnny
On Jan 15, 2010, at 4:00 PM, Mike Sc
this is REALLY non-optimal fetching here, but if it works for you, cool ...
ms
On Jan 15, 2010, at 10:53 PM, Johnny Miller wrote:
> Well at least there is a good reason I didn't find it.
>
> After thinking about the query as SQL I decided to just use the "in"
> qualifier.
>
> i.e. Artist.fetc
oh .. actually this is a qualifier in my own code that isn't in wonder. whoops.
i think there's a houdah one for this?
On Jan 15, 2010, at 8:44 PM, Johnny Miller wrote:
> I'm not familiar with that qualifier (but I've sure been looking for it :) ).
> Can you please point me in the right direct
I'm not familiar with that qualifier (but I've sure been looking for it :) ).
Can you please point me in the right direction or provide an example?
On Jan 15, 2010, at 3:39 PM, Mike Schrag wrote:
> isNotNull only really makes sense on a to-one ... you probably want to use
> the to-many count
isNotNull only really makes sense on a to-one ... you probably want to use the
to-many count qualifier (or something like it) for a to-many.
On Jan 15, 2010, at 8:38 PM, Johnny Miller wrote:
> Hi Mike,
>
> The two entities Artist <->> Artwork
>
> The qualifier is Artist.ARTWORKS.isNotNull()
>
Hi Mike,
The two entities Artist <->> Artwork
The qualifier is Artist.ARTWORKS.isNotNull()
The generated SQL
Thanks a lot,
Johnny
On Jan 15, 2010, at 3:21 PM, Mike Schrag wrote:
> there's more than one entity at play here ... please include example entity
> names and the exact generated
there's more than one entity at play here ... please include example entity
names and the exact generated sql.
On Jan 15, 2010, at 8:18 PM, Johnny Miller wrote:
> Hi,
>
> I'm trying to get a list of entities who has a relationship that is not null
>
> so my ERXKey qualifier looks like
>
> ent
Hi,
I'm trying to get a list of entities who has a relationship that is not null
so my ERXKey qualifier looks like
entity.relationship.isNotNull()
When I look at the SQL generated it is making sure that the primary key of the
entity is not null and it is not looking at the relationship at all.
I have the code to do this ... I'll send it. You get a multipart
iterator on the request and then get a stream from the part.
Sent from my iPhone
On Jan 15, 2010, at 6:41 PM, "Chuck Hill"
wrote:
On Jan 15, 2010, at 1:49 PM, Joe Moreno wrote:
Chuck,
I think the "streamToFilePath" bindi
On Jan 15, 2010, at 1:49 PM, Joe Moreno wrote:
Chuck,
I think the "streamToFilePath" binding is what you need to use.
What bindings are you using?
I'm not using a WODynamicElement (i.e. WOFileUpload). This is a
direct action for third party APIs to call so there is no UI. Or, am
I mis
Chuck,
I think the "streamToFilePath" binding is what you need to use.
What bindings are you using?
I'm not using a WODynamicElement (i.e. WOFileUpload). This is a direct
action for third party APIs to call so there is no UI. Or, am I
misunderstanding your question?
Thanks,
Joe
On
On Jan 15, 2010, at 11:18 AM, Mark Ritchie wrote:
On 15/Jan/2010, at 11:04 AM, Chuck Hill wrote:
On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
Personally, I like the way that EOF is handling the case. It
works for reading and it correctly warns you when you attempt to
change something
On 15/Jan/2010, at 11:17 AM, Chuck Hill wrote:
> OK, good. What you are describing is also what I expect the default 5.4.3
> behaviour to be. We are all good here. :-)
Ah ok, sorry about bending your head on that one... ;-) However, always nice
to have our idea of reality shaken from time to
On 15/Jan/2010, at 11:04 AM, Chuck Hill wrote:
> On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
>> Personally, I like the way that EOF is handling the case. It works for
>> reading and it correctly warns you when you attempt to change something that
>> never existed in the first place. There
On Jan 15, 2010, at 11:14 AM, Mark Ritchie wrote:
On 15/Jan/2010, at 10:52 AM, Chuck Hill wrote:
I wonder if we are mis-communicating. What are you describing
below seems to be the default behavior if NOT using the delegate
method from Kelly Hawk. Is this below result from the code you
On 15/Jan/2010, at 10:52 AM, Chuck Hill wrote:
> I wonder if we are mis-communicating. What are you describing below seems
> to be the default behavior if NOT using the delegate method from Kelly Hawk.
> Is this below result from the code you posted later (Application.java)?
Oh yes, I should
On Jan 15, 2010, at 9:44 AM, Mark Ritchie wrote:
Hi Lon,
On 14/Jan/2010, at 2:21 PM, Lon Varscsak wrote:
heh, it's not. :) I also don't believe that sometimes having an
optional to-one is always a "thing to fix". However, I do understand
now that EOF doesn't handle this case much better tha
On Jan 15, 2010, at 4:04 AM, msch...@mdimension.com wrote:
I thought that as long as bytes are flowing that the request won't
timeout.
Correct. The problem with the non-streaming version (the data
binding, I think) is that Apache would accumulate the _entire_ upload
before passing it to
On Jan 15, 2010, at 12:21 AM, Andrew Lindesay wrote:
Hello Chuck;
Assuming an instance with concurrent request processing turned on,
if there are a number of sessions (or even stateless users) on the
same instance with a large volume of transactions, will the
streaming WORequest multiple
Hi Mark,
On Jan 15, 2010, at 12:08 AM, Mark Ritchie wrote:
Hi Chuck!
On 14/Jan/2010, at 1:46 PM, Chuck Hill wrote:
On Jan 14, 2010, at 3:36 AM, Mark Ritchie wrote:
Yes, I believe that's the intended behaviour... The
DatabaseContext tracks that newly created EO and throws an
exception if
Hi Lon,
On 14/Jan/2010, at 2:21 PM, Lon Varscsak wrote:
> heh, it's not. :) I also don't believe that sometimes having an
> optional to-one is always a "thing to fix". However, I do understand
> now that EOF doesn't handle this case much better than it did in WO4.
Personally, I like the way tha
> So, there are three different flavors? Why "ERX" and "ERXWO" and "Ajax" of
> the same thing?
>
> Perhaps it is just a general rule for understanding Wonder: There are at
> least three ways of doing anything: ak-ish, ms-ish, and ch-ish. :-)
>
> It kind of makes as much sense as any other expla
On Jan 14, 2010, at 3:19 PM, Joe Moreno wrote:
Does anyone have a recommendation on how to manage a file upload
from say, an iPhone, to a WO app (direct action) that takes longer
than the WO adaptor time out? Or, should I just set the WO adaptor
timeout to something like five or ten min
Thank you Mike. I hadn't seen the route controller approach until you
mentioned it. I think it's perfect for our needs - brilliant! We were
already working on the idea that we would have two separate API apps
because one part is mission critical and the other is a less important
layer over
I couldn't get the WSAssistant to work at all. With or without wonder, it
seems totally broken. Also, D2WS in 5.4 will not work with Wonder's D2W,
because it requires that the rule model descends from D2WFastModel or some
such. Also, WOWS fails on WSDLs with XSD imports, so if you are trying t
Pretty sure you can't do this ... I think the entity delegate stuff is entirely
EOEntity-baed. When I made the newer route controller approach, support for
non-entity objects was part of the requirements for it. I started to backport
it to the entity delegates, but it was just too big of a chang
I thought that as long as bytes are flowing that the request won't
timeout. Isn't the adaptor timeout based on lack of activity? I'm with
chuck --- I have an app that does enormous (multigig) uploada to a DA
without any timeouts.
ms
Sent from my iPhone
On Jan 15, 2010, at 12:48 AM, "Chuck
The existing API uses the entity delegate API.
On 14 Jan 2010, at 17:38, Mike Schrag wrote:
> are you use the entity delegate api or the route controller api?
>
> On Jan 14, 2010, at 11:36 AM, Brook, James wrote:
>
>> We have a WebObjects application that uses the ERRest framework to
>> provide a
Hello Anjo;
> When you have - say - two instances and two requests and the one isn't
> finished when the second comes in, yeah, sure. But they close down when they
> are done.
Ok thanks for clarifying that; your account is different to how I had
understood the system worked -- I had previously
Am 15.01.2010 um 09:58 schrieb Andrew Lindesay:
Does each apache handling thread eventually have an on-going
connection to every instance in the deployment?
Yes? No? Doesn't compute?
When you have - say - two instances and two requests and the one isn't
finished when the second comes in, y
Hello Anjo;
Does each apache handling thread eventually have an on-going connection to
every instance in the deployment?
cheers.
> The (apache) adaptor maintains a connection per-thread. So you can easily
> have a slow and a fast request concurrently. Only when they land in the app,
> dependi
The (apache) adaptor maintains a connection per-thread. So you can
easily have a slow and a fast request concurrently. Only when they
land in the app, depending on if you have CCR on or off they will
queue up.
Cheers, Anjo
Am 15.01.2010 um 09:21 schrieb Andrew Lindesay:
Hello Chuck;
Ass
Hello Chuck;
Assuming an instance with concurrent request processing turned on, if there are
a number of sessions (or even stateless users) on the same instance with a
large volume of transactions, will the streaming WORequest multiplex with the
other requests? My understanding was that the We
Hi Chuck!
On 14/Jan/2010, at 1:46 PM, Chuck Hill wrote:
> On Jan 14, 2010, at 3:36 AM, Mark Ritchie wrote:
>> Yes, I believe that's the intended behaviour... The DatabaseContext tracks
>> that newly created EO and throws an exception if you attempt to modify and
>> then save it.
> Almost, it thr
35 matches
Mail list logo