inconsistent selector behaviour

[wilsea]

Not sure why sometimes I get results with a selector, and sometimes I don't,.

I have 180 pages all with the same template with title , description(each is unique) and code (one of 71 different 6 letter string) fields, and all nested under the same page.  Each page displays as expected when viewed directly via it's template or in edit mode. The title is a number string from 1 to 180 (the unique auto-id's from the original source table). No other  templates have a number as the title field. No other pages use the same template.

$pages->find("template=acara_elab") works as expected - 180 pages are returned, and I can display the description and code fields of each returned page.

$pages->find(template=acara_elab, code="xyz") works as expected for the pages (1-98), but fails to find any record 100 and beyond, including searches using the Batcher module.

There are 71 different  codes. The first 98 records use the first 33 codes (all codes are 9 letter strings). The non_displaying codes (in Batcher and from templates other than the original template) all use the last 38 codes.

$pages->find(code="xyz")  works if  "xyz" is any of the first  33 codes, but fails to return results if any of the last 38 codes are used.

Does anyone have any suggestions how to find out what is causing this behaviour?

[nik]

First I'd check and double check the code you're searching for is exactly right - but you must have done that already to be able to give such a detailed description. Still, could those codes for pages 99.. have for example a space in the beginning? To check if the issue is about getting an exact match you could try it out with $pages->find("code%=xyz"). If this gives you the right matches then it has to be something with the data.

To check the data you could see the database directly. Something like "SELECT LENGTH(data), data FROM field_code" will expose codes that have a length different from what you're expecting. Be it a 6 or 9 letter string, don't know which as the length changed in you post .

[wilsea]

Hi Nik

Thanks so much. I didn't even think to try the % contains operator.  It made all the difference  - search works as expect with the %.

I tried the SQL  LENGTH query (haven't struck that before). 

SELECT LENGTH(acara_code), acara_code FROM acara_topics

showed they are all nine characters    Odd.  Still, it works now for whatever reason

Simple instant fix!   

Thanks again!

[MatthewSchenker]

Greetings,

Nice detective work, Nik!

When I read posts like this, where someone says something is not working correctly in ProcessWire, my immediate reaction is, "You're doing something wrong."

Sorry if this sounds harsh, but I have learned to trust ProcessWire that much!

I bring the same judgment to myself.  I've been in many situations where I develop something in ProcessWire and it doesn't do what I expected.  I automatically think, "I must be doing something wrong."

When something "wrong" happens, focus on yourself rather than ProcessWire.

If you adjust your thinking this way, you can streamline troubleshooting.

Thanks,

Matthew

[nik]

Thanks Matthew!

I'm always interested in the cause when someone's got a problem with a selector. Well at least when it's not an obvious one . Often it's a misunderstanding of some kind or a structure complex enough to get anyone dizzy, but then there are those few cases where someone's actually hit a bug or some other kind of bad behaviour. And those are the cases I'm always willing to try and solve.

So, wilsea, I wouldn't say your issue has been fixed. That's only a workaround. Of course it may be one good enough for your particular case, but at least I'm still wondering what's the reason. You checked the code lengths from the original table if I'm not mistaken? Could you run the check against the data in the "field_code" table (if the field is called "code" then that would be the table with the code strings in a field called "data")? Just to rule out the possibility of some inconsistency there. I'm guessing you've generated the pages in PW using a script and there just might be something wrong there.

If everything seems fine there also, could you give a couple of example codes (working and not working ones)? There really has to be some explanation why you've run into this behaviour.

Don't get me wrong - I'm glad you got the expected results and you're probably just fine using this approach. Just being curious .

[wilsea]

Thanks for the continued interest. I'd love to track down what is causing it if possible, but I fear it may be operator error and I'm reluctant to waste people's time  I've been really impressed so far that PW seems to take everything weird thing I try to do in its stride.

The initial slow response (by PW forum standards) had me thinking that I was probably the problem, so I started again with a completely fresh database and completely fresh installation of PW. Even the data was freshly exported from the database. I reimported the data, and the problem was still there. The pages were generated using the ImportPagesFromCSV module.

The data in the PW field_code table looks fine -  all 9 characters. I have another template which uses the same acara_code - it checks out OK in my original data, but I'm not sure where I'd find it inside PW - it's a property of my Details template, which uses an autogenerated id from my original database table as the title field. It's highly unlikey that it is any different , since the database data was generated using a program which used  the same variable for each database table. Both tables use a TINYTEXT field for the acara_code column in the source database.

Codes 1486 through to 1583 all work, but 1584 to 2430 don't work.

(how do people do those neat thumbnails?)

The breakpoint for the codes that work and those that don't are related to the top level table of a  straight forward series of one to many tables.

My heirachy is  Subject > Strand >Substrand >Topics > Details.

Strand       (strand_id,strand_subject,strand_name)

Substrand (substrand_id,substrand_name, strand_id)

Topics       (code_id,substrand_id,code,code-detail,level)

Details       (detail_id,code,topic-detail)

The six Subject pages were created from the admin panel using Batcher- all children of a hidden Subjects page.

The other pages are all created using the ImportPagesFromCSV module.

The code is used to link the Code and Details tables - and that's the only time it is used.

Codes 1486 through to 1583 all work, but 1584 to 2430 don't work.  However the searches work fine for the codes with the first great grandparent in the subject table. All codes that can be traced back to any other great grandparent Subject (there are 5 in total) don't work.

I don't see any reason why that relationship should cause a problem - maybe it's a red herring co-incidence. However it's also the only thing I can find about the codes that work and the ones that don't. 

It might well be that I'm doing something wrong, but I've run out of ideas for what else I can do of check to find out what's going on. 

Over to the detective squad! 

[wilsea]

Just found the Selector Test module, and I get exactly the same results in it as I do with the Batcher module.

[ryan]

This might be too complex of a scenario for me to reproduce very easily here. I wonder if I could get a copy of the database, or at least an export of the field_acara_code table? Also wanted to check if you've tried to run a DB table repair on the field_acara_code table? If this issue isn't due to some stray character or encoding issue in the table data, then it sounds like potentially a broken index, or some MySQL index behavior I'm not aware of. It's interesting to me that '%=' worked while '=' didn't, because '%=' bypasses the index, doing a full table scan, whereas '=' uses the index. It might also be good to know what version of MySQL? 

[wilsea]

Thanks for your interest Ryan. 

The problem is at my end, as anticipated. It just took me hours and hours to realize that although all the codes were 9 nine letters, some of them should have been 8 letters, and the 8 letter ones are padded with a space at the front.  Aaaarrrgggghhhhh. How could I be so blind. Please accept my apologies for wasting people's time.

I'm uber impressed with PW - a joy to use and awesome support.

I'm basically a retired hobbyist relying heavily on google and StackOverflow for programming knowledge. I started out with  Wordpress , found that it was a pain t to customise, so was Drupal,  CodeIgniter didn't light my fire, and Laravel assumed far more coding knowledge than I have. But for me PW ticks all the boxes - easy to learn, easy to use, helps you learn PHP and build a site that does what you want it to. 

Thankyou for making this product open-source. It's a game changer.

I started with a brand new database

[ryan]

No problem. Glad you got it sorted out.