<br><br><div class="gmail_quote">On Tue, May 29, 2012 at 9:03 AM, James Aylett <span dir="ltr"><<a href="mailto:james-xapian@tartarus.org" target="_blank">james-xapian@tartarus.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF"><div>I'd say it's better than to refuse to compile, although it's somewhat moot right now. All numbers will overflow eventually, although I assume in Node yo'd just get IEEE rounding behaviour? Basically, there's no nice solution.</div>
</div></blockquote><div><br>It would be a runtime check, not compile-time. We'd compile against a suitably configured Xapian :-)<br><br>In what context are int64 doc ids necessary? What % of installations use them?<br>
</div><div bgcolor="#FFFFFF"><div><br></div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div> Slicing / comprehension I mean you return an object that will act as an array but which doesn't read out the data at that point. Obviously has interesting interactions with the async model of Node, but having to think about paging seems like a step back from nice abstractions to me :-(<br>
</div></div></blockquote><div><br>Well you know what they say about "nice abstractions"... The road to Hell is paved with them :-) <br><br>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...<br>
</div></div>