anonymous user

Forums   Register   Login   Forgot your login/password?   Search

"no field X found in schema" after upgrade to 0.9.8-release

Common forum | 1 | 2 | 3 | 4 | 5 | ... | 523 | 524 | 525 | 526 | next »» | Create new thread

barryhunter

Name: Barry Hunter
Posts: 7417

2008-08-19 16:53:47 | reply!


We recently tried upgrading from 0.9.7 to 0.9.8-release, but run into a problem

Source for the index:
----
                sql_query = \
                                SELECT gi.gridimage_id, UNIX_TIMESTAMP(gi.submitted) AS submitted, \
                              <more columns>
                                (gi.reference_index * 10000000 + (viewpoint_northings div 1000) * 1000 +
                                viewpoint_eastings div 1000) AS viewsquare \
                                FROM gridimage_search gi\
                              <more tables>
                                WHERE gi.gridimage_id<=( SELECT max_doc_id FROM sph_counter WHERE
                                counter_id='gridimage_search' )
                sql_date_column = submitted
                sql_attr_uint = viewsquare
----

And then would run extended queries like:

@viewsquare 10350250 @grid_reference -sh5050

which worked great on 0.9.7, but gives the following error on 0.9.8

WARNING: index gi_stemmed: query error: no field 'viewsquare' found in schema


I can only guess that as we are specifically declaring 'viewsquare' to be an attribute
column, its not then available in extended match mode.

So I suspect that we can fix it by moving the viewsquare condition to be a specific
attribute filter (using SetFilter) - which we do in other places, but it was nice to be
able to just add it to the query.


However we rolled back now to 0.9.7, and will try it out a bit more before upgrading
again, but on thing that does occur to me now is didnt rebuild the index files after
upgrading, should we have done? Would that avoid this issue?


Thanks for any insight!



btw, the config file barely changed between versions, just changed strip_html and
sql_date_column to sql_attr_timestamp as it reported these depreciated.

shodan

Name: Andrew Aksyonoff
Posts: 4360

to: barryhunter, 2008-08-28 16:37:34 | reply!


> I can only guess that as we are specifically declaring 'viewsquare' to be an attribute
> column, its not then available in extended match mode.

Right. Every source SQL column ends up being either a numeric attribute or a fulltext
field; not both. @field syntax is for fulltext fields. Your query should not really had
worked even in 0.9.7; that was a bug. :)

> So I suspect that we can fix it by moving the viewsquare condition to be a specific
> attribute filter (using SetFilter) - which we do in other places, but it was nice to be
> able to just add it to the query.

Clone it. Ie. select it twice (under different names), make one copy an attribute, and
another one a fulltext field.

> didnt rebuild the index files after upgrading, should we have done? Would that avoid this
> issue?

Normally you should but I don't think rebuild should affect *this* issue.

> btw, the config file barely changed between versions, just changed strip_html and
> sql_date_column to sql_attr_timestamp as it reported these depreciated.

We're keeping backwards compatibility as much as we can :)

barryhunter

Name: Barry Hunter
Posts: 7417

to: shodan, 2008-08-28 17:26:37 | reply!


Thanks for the informative reply!

> > I can only guess that as we are specifically declaring 'viewsquare' to be an attribute
> column, its not then available in extended match mode.
>
> Right. Every source SQL column ends up being either a numeric attribute or a fulltext
> field; not both. @field syntax is for fulltext fields. Your query should not really had
> worked even in 0.9.7; that was a bug. :)

Ah ok, at least we know a 'reason' :)

>
> > So I suspect that we can fix it by moving the viewsquare condition to be a specific
> attribute filter (using SetFilter) - which we do in other places, but it was nice to be
> able to just add it to the query.
>
> Clone it. Ie. select it twice (under different names), make one copy an attribute, and
> another one a fulltext field.

Yes that is what will do. At the moment, just changed the uses of setFilter to add it to
the query for now so just using the full-text match method :)

>
> > didnt rebuild the index files after upgrading, should we have done? Would that avoid
> this issue?
>
> Normally you should but I don't think rebuild should affect *this* issue.

I ended up reindexing all anyway just to be sure, the second time round.

>
> > btw, the config file barely changed between versions, just changed strip_html and
> sql_date_column to sql_attr_timestamp as it reported these depreciated.
>
> We're keeping backwards compatibility as much as we can :)

  Other than this initial issue 0.9.8 seems to be working well :)

Common forum | 1 | 2 | 3 | 4 | 5 | ... | 523 | 524 | 525 | 526 | next »» | Create new thread