sql_query = SELECT "features"."id" * 9 + 0 AS "id", "features"."title" AS
"title", "features"."body" AS "body", "features"."id" AS
"sphinx_internal_id", 'Feature' AS "sphinx_internal_class", 0 AS
"sphinx_deleted" FROM "features" WHERE ("features"."id" BETWEEN $start AND
$end AND status = 'published') GROUP BY "features"."id",
"features"."title", "features"."body", "features"."id"
sql_query_range = SELECT COALESCE(MIN("features"."id"), 1),
COALESCE(MAX("features"."id"), 1) FROM "features"
sql_query = SELECT "posts"."id" * 9 + 1 AS "id", "posts"."title" AS
"title", "posts"."tagline" AS "tagline", "posts"."tags" AS "tags",
"posts"."body" AS "body", "posts"."id" AS "sphinx_internal_id", 'Post' AS
"sphinx_internal_class", 0 AS "sphinx_deleted" FROM "posts" WHERE
("posts"."id" BETWEEN $start AND $end AND status = 'published') GROUP BY
"posts"."id", "posts"."title", "posts"."tagline", "posts"."tags",
"posts"."body", "posts"."id"
sql_query_range = SELECT COALESCE(MIN("posts"."id"), 1),
COALESCE(MAX("posts"."id"), 1) FROM "posts"
On Wednesday, May 6, 2015 at 4:32:12 PM UTC+10, Pat Allan wrote:
>
> Hi Robbie
>
> What does the sql_query line look for the other two models? Given the
> query results you’ve shared were across story, feature and post indices,
> it’s possible the dud match wasn’t a story. Certainly (as you’ve likely
> spotted), sphinx_internal_class in the story index is ‘Story’, so I don’t
> think that index is the cause of the issue.
>
> —
> Pat
>
> On 6 May 2015, at 4:23 pm, Robbie Shepherd <[email protected]
> <javascript:>> wrote:
>
> Hi Pat,
>
> I re-ran the index rake task last night and it "seems" to be ok now. I'm
> unable to ascertain though if there are any remaining records where
> sphinx_internal_class is null (as sphinxql doesnt seem to recognise NULL's)
> - any pointers there?
>
> Also, you mentioned checking the sql_query for stories in conf file:
>
> source story_core_0
> {
> type = pgsql
> sql_host = localhost
> sql_user = robbie
> sql_pass = postgres
> sql_db = ynn_development
> sql_query_pre = SET TIME ZONE UTC
> sql_query = SELECT "stories"."id" * 9 + 2 AS "id", "stories"."heading"
> AS "heading", "stories"."tagline" AS "tagline", "stories"."tags" AS "tags",
> "stories"."id" AS "sphinx_internal_id", 'Story' AS "sphinx_internal_class",
> 0 AS "sphinx_deleted", "stories"."category_id" AS "category_id" FROM
> "stories" WHERE ("stories"."id" BETWEEN $start AND $end AND status =
> 'published') GROUP BY "stories"."id", "stories"."heading",
> "stories"."tagline", "stories"."tags", "stories"."id",
> "stories"."category_id"
> sql_query_range = SELECT COALESCE(MIN("stories"."id"), 1),
> COALESCE(MAX("stories"."id"), 1) FROM "stories"
> sql_attr_uint = sphinx_internal_id
> sql_attr_uint = sphinx_deleted
> sql_attr_uint = category_id
> sql_attr_string = sphinx_internal_class
> sql_query_post_index = UPDATE "stories" SET "delta" = FALSE WHERE
> "delta" = TRUE
> sql_query_info = SELECT "stories".* FROM "stories" WHERE
> ("stories"."id" = ($id - 2) / 9)
> }
>
>
>
>
>
>
> On Tuesday, May 5, 2015 at 7:27:50 PM UTC+10, Pat Allan wrote:
>>
>> So, is it definitely story records that have the problem? (remove other
>> indices from that query to check). The sphinx_internal_id attribute is the
>> model’s primary key, so that may be useful for debugging… Also worth
>> looking at the sql_query value for that specific source in
>> config/development.sphinx.conf locally, see where that
>> sphinx_internal_class value is coming from and possibly going wrong (it
>> could be a type column, perhaps?)
>>
>> —
>> Pat
>>
>> On 5 May 2015, at 7:14 pm, Robbie Shepherd <[email protected]> wrote:
>>
>> your theory is confirmed - searches that are fine all return results with
>> sphinx_internal_class of Story. Searches that I know fail all have one
>> result (or maybe more) with a nil value for sphinx_internal_class - now how
>> do we stop this from happening?
>>
>> Thanks for your help so far!
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Thinking Sphinx" 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/thinking-sphinx.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Thinking Sphinx" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]
> <javascript:>.
> Visit this group at http://groups.google.com/group/thinking-sphinx.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Thinking Sphinx" 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/thinking-sphinx.
For more options, visit https://groups.google.com/d/optout.
