Ignore last :)
We've figured it out:
Application.eager_graph(:irs => [:releases,:deployments => [:build]
> ]).select(
Is there a better way of doing this? it seems like it going to get rather
messy quite soon :)
On Friday, 6 June 2014 16:30:15 UTC+10, Dean Cornish wrote:
>
> One additional question- a long the same lines-
>
> Having gotten past that hurdle with your help, we're now running into the
> next logical problem with a normalised table set.
> We've attached our planned table structure.
> The issue we face is that when we incorporate the next logical step- eg.
>
> Many deployments have one build each.
> Writing the eager_graph query is throwing us- because what does work *without
> build* is below-
>
>> Application.eager_graph(:irs => [:deployments, :releases]).select(...
>
>
> However, what we need is to is pull in deployment's build as well.
>
> Any thoughts? it doesn't seem obvious to us.
>
> Cheers,
>
> Dean
>
>
> On Friday, 6 June 2014 14:55:47 UTC+10, Dean Cornish wrote:
>>
>> Thank you so much!
>>
>> You're a fantastic reader, and really got what we were trying to do.
>> For now, we're happy with eager_graph- but your point is well heeded and
>> we'll investigate the alternate output needed for csv.
>> We are primarily building a JSON web service on Sinatra, so for now this
>> will be fine.
>> Once we wrapped our heads around the semantics of the model- we realise
>> how powerful it is, and how accessible it is.
>> Thank you! a truly great library- appreciate all your help Jeremy :)
>>
>> Dean + Adarsh
>>
>> On Friday, 6 June 2014 13:09:15 UTC+10, Jeremy Evans wrote:
>>>
>>> On Thursday, June 5, 2014 7:30:17 PM UTC-7, Dean Cornish wrote:
>>>>
>>>> Hi All,
>>>>
>>>> My dev pair and I are struggling a little bit-
>>>> See attached.
>>>> We can successfully navigate up and down on either side eg. App -> IR
>>>> -> Depl and back again using:
>>>>
>>>> Given a Model structure of:
>>>>
>>>> class Application < Sequel::Model
>>>> many_to_many :irs
>>>> end
>>>>
>>>> class Ir< Sequel::Model
>>>> many_to_many :applications
>>>> many_to_many :releases
>>>> many_to_many :deployments
>>>> end
>>>>
>>>> class Release < Sequel::Model
>>>> many_to_many :irs
>>>> end
>>>>
>>>> class Deployment < Sequel::Model
>>>> many_to_many :irs
>>>> end
>>>>
>>>>
>>>> #this returns everything linked from a releases up the chain in
>>>> reverse
>>>> Application.eager_graph(:irs => :releases).each {
>>>> |t| puts "Applications down through to Releases: #{t.inspect}\n"
>>>> }
>>>>
>>>> and
>>>>
>>>> #this returns everything linked from a release up the chain in reverse
>>>> Release.eager_graph(:irs => :applications).each {
>>>> |t| puts "Release up through to Applications: #{t.inspect}"
>>>> }
>>>>
>>>> We can trivially modify the above to traverse Deployments and
>>>> Applications in both directions.
>>>>
>>>> The issue- if you can help us- is with how do we have a single query
>>>> that returns Application -> Irs and both Releases and Deployments
>>>> something
>>>> like:
>>>>
>>>> This is of course- fantasy code- but if you can help us to understand
>>>> what might achieve this kind of outcome - it would be great. We're newbies
>>>> with sequel :)
>>>>
>>>> #this returns just the fields we want for csv and other export
>>>> Application.eager_graph([:irs => :deployments, irs =>
>>>> releases]).select(:applications__application_name, :irs__ir_name,
>>>> :releases__release_name, :deployments__deployment_number).each {
>>>> |t| puts "Applications down via irs to both Release and
>>>> Deployments: #{t.values}"
>>>> }
>>>>
>>>> Any help you can provide would be awesome :)
>>>>
>>>
>>> You were almost there:
>>>
>>> Application.eager_graph(:irs => [:deployments, releases])
>>>
>>> Note that you have to use set_graph_aliases instead of select when using
>>> eager_graph. However, for a csv export, an eager_graph is probably not
>>> what you want, since eager_graph provides a object graph, and CSV really
>>> deals best with a table (array of arrays). You probably want to use
>>> association_join/association_left_join instead of eager_graph for a csv
>>> export (in which case you can continue to use select, or maybe even
>>> select_map). For a json export, you would probably want to use eager_graph
>>> or something similar.
>>>
>>> Note that you need to understand what is going on at an SQL level if you
>>> use eager_graph. With the code given above, you could be generating huge
>>> results sets due to the cartesian products involved. For example, if you
>>> were eager loading 100 apps, and each had 100 irs, and each of those irs
>>> had 100 releases and 100 deployments, you are looking at 100,000,000 rows
>>> in the returned result set. Unless you are filtering or ordering based on
>>> columns in the associated table, you are probably better off using eager
>>> instead of eager_graph.
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
