Hi all, The Catalog tab in my catalog says this: The catalog "mycatalog" contains 30,345 record(s) in the path "/". But when I sort and return a list of cataloged objects I only have 19,881. Here is the script call to retrieve the records: context.mycatalog.search( {}, sort_index='lastname' ) Why don't the numbers match up? -d
--On 14. Juni 2008 15:15:17 -0700 Darryl Caldwell <darryl.caldwell@gmail.com> wrote:
Hi all,
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Corrupt catalog? Reindex (ZMI -> catalog -> Advanced tab -> Update catalog). -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Darryl Caldwell wrote:
Hi all,
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Some of your objects don't have a 'lastname' attribute, and so when sorting, they get dropped. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVXkf+gerLs4ltQ4RAun4AJ0X8whmA8ABUqkn1bAWIMqv3utX+ACZAV8y YQCLz6XhuBvLn8rAF65Q4L4= =6XZ+ -----END PGP SIGNATURE-----
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Some of your objects don't have a 'lastname' attribute, and so when sorting, they get dropped.
Should we not consider this a bug and fix it? -- Dieter
--On 19. Juni 2008 20:35:29 +0200 Dieter Maurer <dieter@handshake.de> wrote:
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up?
Some of your objects don't have a 'lastname' attribute, and so when sorting, they get dropped.
Should we not consider this a bug and fix it?
+1 for the bug prospective :-) Andreas
Dieter Maurer wrote:
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up? Some of your objects don't have a 'lastname' attribute, and so when sorting, they get dropped.
Ah, now that's interesting...
Should we not consider this a bug and fix it?
Yes, this has bitten me before and I have a feeling I may have already submitted it as a bug somewhere. Google is your friend... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote:
Tres Seaver wrote at 2008-6-15 16:18 -0400:
...
The Catalog tab in my catalog says this:
The catalog "mycatalog" contains 30,345 record(s) in the path "/".
But when I sort and return a list of cataloged objects I only have 19,881.
Here is the script call to retrieve the records:
context.mycatalog.search( {}, sort_index='lastname' )
Why don't the numbers match up? Some of your objects don't have a 'lastname' attribute, and so when sorting, they get dropped.
Should we not consider this a bug and fix it?
If you can specify the "fixed" behavior in a way that makes logical sense to everyone: - how should the documents without 'lastname' be sorted? - Is this choice fixed at indexing time or can it vary by query? Any proposed fix must also not: - break existing applications which depend on the current behavior (yes, they exist, I've found that quite useful). Therefore, making "missing" values sort needs to be an option which is configured into the index, or else passed with the query. - destroy the efficiency considerations which dictated the choice in the first place. This is the *hard* part. Using the sorted UIDs from the sort index, and merging with the other indexes sets lazily, gives a *huge* scaling benefit. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIXHvN+gerLs4ltQ4RAhGpAJ9MvaNf3dUNSrTp9hCoHyZYSHMJeQCeKByA nGIcxZ3pzcyOl5GBTo75qOA= =PXJ+ -----END PGP SIGNATURE-----
participants (5)
-
Andreas Jung -
Chris Withers -
Darryl Caldwell -
Dieter Maurer -
Tres Seaver