Hi Christian,

I don't use the sequel ORM at all actually. Let say that some business 
logic of my app needs to know the indexes of a given SQL table. For this I 
use `DB.indexes(:table_name)`. The query I've shown is the one generated by 
sequel itself to answer the question.

There's nothing about sinatra indeed ;-)

B

On Friday, September 21, 2012 11:37:47 PM UTC+2, Christian MICHON wrote:
>
> On Fri, Sep 21, 2012 at 8:31 PM, blambeau <[email protected] <javascript:>> 
> wrote: 
> > Oh sorry. 
> > 
> > Postgresql. The kind of query that is repeating over and over again: 
> > 
> > SELECT "indc"."relname" AS "name", "ind"."indisunique" AS "unique", 
> > "att"."attname" AS "column" FROM "pg_class" AS "tab" INNER JOIN 
> "pg_index" 
> > AS "ind" ON (("ind"."indrelid" = "tab"."oid") AND ('game_games' = 
> > "tab"."relname")) INNER JOIN "pg_class" AS "indc" ON ("indc"."oid" = 
> > "ind"."indexrelid") INNER JOIN "pg_attribute" AS "att" ON 
> (("att"."attrelid" 
> > = "tab"."oid") AND ("att"."attnum" = ANY("ind"."indkey"))) WHERE 
> > (("indc"."relkind" = 'i') AND ("ind"."indisprimary" IS FALSE) AND 
> > ("indexprs" IS NULL) AND ("indpred" IS NULL) AND ("indisvalid" IS TRUE) 
> AND 
> > ("indisready" IS TRUE) AND ("indcheckxmin" IS FALSE)) ORDER BY 
> > "indc"."relname", (CASE "att"."attnum" WHEN "ind"."indkey"[0] THEN 0 
> WHEN 
> > "ind"."indkey"[1] THEN 1 WHEN "ind"."indkey"[2] THEN 2 WHEN 
> > "ind"."indkey"[3] THEN 3 WHEN "ind"."indkey"[4] THEN 4 WHEN 
> > "ind"."indkey"[5] THEN 5 WHEN "ind"."indkey"[6] THEN 6 WHEN 
> > "ind"."indkey"[7] THEN 7 WHEN "ind"."indkey"[8] THEN 8 WHEN 
> > "ind"."indkey"[9] THEN 9 WHEN "ind"."indkey"[10] THEN 10 WHEN 
> > "ind"."indkey"[11] THEN 11 WHEN "ind"."indkey"[12] THEN 12 WHEN 
> > "ind"."indkey"[13] THEN 13 WHEN "ind"."indkey"[14] THEN 14 WHEN 
> > "ind"."indkey"[15] THEN 15 WHEN "ind"."indkey"[16] THEN 16 WHEN 
> > "ind"."indkey"[17] THEN 17 WHEN "ind"."indkey"[18] THEN 18 WHEN 
> > "ind"."indkey"[19] THEN 19 WHEN "ind"."indkey"[20] THEN 20 WHEN 
> > "ind"."indkey"[21] THEN 21 WHEN "ind"."indkey"[22] THEN 22 WHEN 
> > "ind"."indkey"[23] THEN 23 WHEN "ind"."indkey"[24] THEN 24 WHEN 
> > "ind"."indkey"[25] THEN 25 WHEN "ind"."indkey"[26] THEN 26 WHEN 
> > "ind"."indkey"[27] THEN 27 WHEN "ind"."indkey"[28] THEN 28 WHEN 
> > "ind"."indkey"[29] THEN 29 WHEN "ind"."indkey"[30] THEN 30 WHEN 
> > "ind"."indkey"[31] THEN 31 ELSE 32 END) 
> > 
> > B 
> > 
>
> If your app is based on sinatra+sequel, what is coded using sequel ORM? 
>
> I'm curious about the case with 32 possibilities. What is it for? 
>
> I would believe this complex SQL might be the issue more than sinatra 
> itself, nor sequel. 
>
> I do not use postgresql, though I did evaluate it. I use h2 database 
> on jruby, allowing to use prepared statements for such complex 
> business logic. It is compiled once, and it does help gaining some 
> speed. 
>
> Can you make a small sinatra testcase then? 
>
> As for DB.tables not being cached, you were talking about memoization 
> then, right? 
>
> -- 
> Christian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/sequel-talk/-/iyYxR23r8mcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en.

Reply via email to