Content preview: Леонид Юрьев wrote: > Thanks, Howard. > > It would
be nice if some clarification, like these, will be in the lmdb.h. MDB_INTEGERDUP
is already clearly documented. > > Leonid. > > 2015-05-01 4:42 GMT+03:00
Howard Chu <***@symas.com>: >> Леонид Юрьев wrote: >>> >>> Hi,
Howard. >>> >>> I would like to refine my question. >>> >>> Currently I develop
a mdb_chk tool for deep check LMDB-files, like a fsck >>> tool. >>> It is
needed for us, but let this stay aside for now. >>> >>> On some step I plan
to check the size of each key in each DBI with >>> MDB_INTEGERKEY and/or
MDB_INTEGERDUP flags. >>> >>> Initially I assumed - if one of these flags
is set, the the length of >>> all keys must be sizeof(int) or sizeof(long).
As will be used the >>> corresponding comparison functions (mdb_cmp_int,
mdb_cmp_long) , which >>> can handle only keys of such sizes. >>> >>> But
this approach has failed. A dbi-tables created for attr by >>> mdb_attr_dbs_open()
have MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP flags >>> and may contain records
with a 5-byte keys. For instance as the >>> 'entryCSN'. >>> >>> Later you
have written that MDB_INTEGERDUP is required. >>> >>> Now I do not understand
how it all works: >>> - MDB_INTEGERDUP is set for attr tables. >>> - indexer
could create a 5-byte keys. >>> - mdb-backend set custom comparison function
only for MDB_DN2ID table. >>> - under debugger I see that md_dcmp is pointed
to the default. >>> - assert for key-size in default comparators was not
failed while "make >>> test". >>> - all test are passed without MDB_INTEGERDUP.
Post by Howard Chu- but you told MDB_INTEGERDUP is necessary >>> >>> So, >>> - how and
when MDB_INTEGERDUP will have an impact? >>> - in which cases keys in the
table definitely should be sizeof(int) or >>> sizeof(long)? >> >> >> MDB_INTGERKEY
means the *keys* must be int/long. >> MDB_INTEGERDUP means the *values* must
be int/long. >> >> When either flag is set, all of the corresponding (keys|values)
in the DB >> must be the same size. >> >> The indexer only uses MDB_INTEGERDUP
- it doesn't care what size the keys >> are, but the values must be (longs
in this case). >> >> -- >> -- Howard Chu >> [...]
Content analysis details: (-4.2 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
Cc: openldap-***@openldap.org
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-devel/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-devel-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=subscribe>
Errors-To: openldap-devel-***@openldap.org
Sender: "openldap-devel" <openldap-devel-***@openldap.org>
X-Spam-Score: -4.2 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Леонид Юрьев wrote: > Thanks, Howard. > > It would
be nice if some clarification, like these, will be in the lmdb.h. MDB_INTEGERDUP
is already clearly documented. > > Leonid. > > 2015-05-01 4:42 GMT+03:00
Howard Chu <***@symas.com>: >> Леонид Юрьев wrote: >>> >>> Hi,
Howard. >>> >>> I would like to refine my question. >>> >>> Currently I develop
a mdb_chk tool for deep check LMDB-files, like a fsck >>> tool. >>> It is
needed for us, but let this stay aside for now. >>> >>> On some step I plan
to check the size of each key in each DBI with >>> MDB_INTEGERKEY and/or
MDB_INTEGERDUP flags. >>> >>> Initially I assumed - if one of these flags
is set, the the length of >>> all keys must be sizeof(int) or sizeof(long).
As will be used the >>> corresponding comparison functions (mdb_cmp_int,
mdb_cmp_long) , which >>> can handle only keys of such sizes. >>> >>> But
this approach has failed. A dbi-tables created for attr by >>> mdb_attr_dbs_open()
have MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP flags >>> and may contain records
with a 5-byte keys. For instance as the >>> 'entryCSN'. >>> >>> Later you
have written that MDB_INTEGERDUP is required. >>> >>> Now I do not understand
how it all works: >>> - MDB_INTEGERDUP is set for attr tables. >>> - indexer
could create a 5-byte keys. >>> - mdb-backend set custom comparison function
only for MDB_DN2ID table. >>> - under debugger I see that md_dcmp is pointed
to the default. >>> - assert for key-size in default comparators was not
failed while "make >>> test". >>> - all test are passed without MDB_INTEGERDUP.
Post by Howard Chu- but you told MDB_INTEGERDUP is necessary >>> >>> So, >>> - how and
when MDB_INTEGERDUP will have an impact? >>> - in which cases keys in the
table definitely should be sizeof(int) or >>> sizeof(long)? >> >> >> MDB_INTGERKEY
means the *keys* must be int/long. >> MDB_INTEGERDUP means the *values* must
be int/long. >> >> When either flag is set, all of the corresponding (keys|values)
in the DB >> must be the same size. >> >> The indexer only uses MDB_INTEGERDUP
- it doesn't care what size the keys >> are, but the values must be (longs
in this case). >> >> -- >> -- Howard Chu >> [...]
Content analysis details: (-4.2 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[69.43.206.106 listed in list.dnswl.org]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
Thanks, Howard.
It would be nice if some clarification, like these, will be in the lmdb.h.
MDB_INTEGERDUP is already clearly documented.
Leonid.
Post by Howard ChuHi, Howard.
I would like to refine my question.
Currently I develop a mdb_chk tool for deep check LMDB-files, like a fsck tool.
It is needed for us, but let this stay aside for now.
On some step I plan to check the size of each key in each DBI with
MDB_INTEGERKEY and/or MDB_INTEGERDUP flags.
Initially I assumed - if one of these flags is set, the the length of
all keys must be sizeof(int) or sizeof(long). As will be used the
corresponding comparison functions (mdb_cmp_int, mdb_cmp_long) , which
can handle only keys of such sizes.
But this approach has failed. A dbi-tables created for attr by
mdb_attr_dbs_open() have MDB_DUPSORT|MDB_DUPFIXED|MDB_INTEGERDUP flags
and may contain records with a 5-byte keys. For instance as the
'entryCSN'.
Later you have written that MDB_INTEGERDUP is required.
- MDB_INTEGERDUP is set for attr tables.
- indexer could create a 5-byte keys.
- mdb-backend set custom comparison function only for MDB_DN2ID table.
- under debugger I see that md_dcmp is pointed to the default.
- assert for key-size in default comparators was not failed while "make test".
- all test are passed without MDB_INTEGERDUP.
- but you told MDB_INTEGERDUP is necessary
So,
- how and when MDB_INTEGERDUP will have an impact?
- in which cases keys in the table definitely should be sizeof(int) or
sizeof(long)?
MDB_INTGERKEY means the *keys* must be int/long.
MDB_INTEGERDUP means the *values* must be int/long.
When either flag is set, all of the corresponding (keys|values) in the DB
must be the same size.
The indexer only uses MDB_INTEGERDUP - it doesn't care what size the keys
are, but the values must be (longs in this case).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/