[
http://issues.apache.org/jira/browse/LUCENE-460?page=comments#action_12361200 ]
Yonik Seeley commented on LUCENE-460:
-
Some people have asked where some of the magic constants come from in the
hashCodes:
> python -c "import random;print hex(random.ge
Here is my previous reply to Otis:
> python -c "import random;print hex(random.getrandbits(32))[:-1]"
> Just a way of making some things unique let me know if you have a
> better idea on that.
So those constants are just random numbers. I thought about trying to
pick magic numbers to maximiz
I suspect it's a little too ambitious to provide a
unifying common abstraction which wraps event based
*and* "pull" parser approaches.
I'm personally happier to stick with one approach,
preferably with an existing, standardized interface
which lets me switch implementations. I didn't really
want
Hi
Can u plz tell me if i have to ask any doubt so where should i mail.
Regards,
Aruna Rawat
(Software Engineer)
Patni Computer Systems,
Millennium Business Park,
Mahape, Navi Mumbai 400 710
Phone: 022-27783600, Ext: 1708
-Original Message-
From: Steven Pannell [mailto:[EMAIL PROTE
Hi,
Question about latest cvs changes and hashcodes.
http://issues.apache.org/jira/browse/LUCENE-460
Could anybody explain the magic numbers? 0x6634D93C,0x2742E74A and other.
Any special meaning? Is this documented anywhere?
Pasha
--
Hi,
Yes, I can see why in this implementation it will not work. However, what
about using the XMLEncoder instead of Serializable? Using this method we
have both platform and class object independence. That would solve it.
Steve.
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PR
On Dec 23, 2005, at 5:00 AM, Steven Pannell wrote:
Can someone please tell my why the Document class has no interface
and is
final?
Primarily because Lucene controls the construction of Document
instances returned from Hits.
I want to create some documents that have some standard fields
Hi,
Can someone please tell my why the Document class has no interface and is
final?
I want to create some documents that have some standard fields (eg: creation
date), and I don't want to keep repeating my code. This way I ensure some
standard conventions in all my documents.
What's the reason
: > I think that the ideal API wouldn't require people
: > writing ObjectBuilders
: > to know anything about sax, or to ever need to
: > import anything from
: > org.xml.** or javax.xml.**
:
: Fair enough. I presume we want to maintain the
: position that Lucene should not have any dependencies
: o
