[Xapian-devel] GSoC xapian node binding thoughts

[Marius Tibeica]

> On Thu, May 31, 2012 at 1:34 AM, Liam <xapian at networkimprov.net> wrote:
>
>> On Tue, May 29, 2012 at 7:24 PM, Olly Betts <olly at survex.com> wrote:
>>
>>> If you change sizeof(Xapian::docid) (and/or the sizes of other types)
>>> then that's an ABI change, so something built against xapian-core built
>>> with one docid size simply won't work with xapian-core built with a
>>> different docid size.
>>>
>>
>> So what happens when our lib tries to load or invoke the incompatible
>> Xapian? Is it possible to prevent a crash?
>>
>>>
>> > In what context are int64 doc ids necessary? What % of installations use
>>> > them?
>>>
>>> I doubt may people use them currently, quite possibly nobody does.  But
>>> that's likely to change in the foreseeable future.  We're probably near
>>> the point where you could conceivably build an index with this many
>>> documents on commodity hardware.
>>>
>>
>> We can support more than 2^32 values by converting to double (JS type
>> Number) for 2^53. But beyond that the values stop converting correctly,
>> meaning we'd throw an overflow and the user would have to hack the binding
>> himself.
>>
>> Marius can you make a note to treat docid as a Number instead of uint32,
>> and check the values from Xapian for overflow?
>>
> Will do.

>
>>
>> > Seriously, lazy-loading is oversold from what I've seen. If you have
>>> data
>>> > from real-world Xapian sites that shows a material advantage for it,
>>> I'd
>>> > love to read...
>>>
>>> Any site searching a large Xapian database is relying heavily on lazy
>>> loading.
>>>
>>
>> For an array, it's necessary, so we'll take start & count args when
>> building arrays. For objects, I question the value of lazy loading, save
>> for very large fields.
>>
> For example we currently have (in quickstartsync.js) var mset=enquire.
get_mset_sync(0, 10);
I will update docs.md as i write the code for every method that requires
this.

>
>>
>> _______________________________________________
>> Xapian-devel mailing list
>> Xapian-devel at lists.xapian.org
>> http://lists.xapian.org/mailman/listinfo/xapian-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120531/f9e695b3/attachment-0001.htm>