On Tue, 10 Jul 2012, Andi Vajda wrote:
I would also like to propose a change, to allow for more flexible
mechanism of generating Python class names. The patch doesn't change
the default pylucene behaviour, but it gives people a way to replace
class names with patterns. I have noticed that there are more
same-name classes from different packages in the new lucene (and it
becomes worse when one has to deal with both lucene and solr).
Another way to fix this is to reproduce the namespace hierarchy used in
Lucene, following along the Java packages, something I've been dreading to
do. Lucene just loooooves a really long deeply nested class structure.
I'm not convinced yet it is bad enough to go down that route, though.
Your proposal to use patterns may in fact yield a much more convenient
solution. Thanks !
Rethinking this a bit, I'm prepared to change my mind on this. Your
patterned rename patch shows that we're slowly but surely reaching the limit
of the current setup that consists in throwing all wrapped classes under the
one global 'lucene' namespace.
Lucene 4.0 has seen a large number of deeply nested classes with similar
names added since 3.x. Renaming these one by one (or excluding some) doesn't
scale. Using the proposed patterned rename scales more but makes it
difficult to know what got renamed and how.
Ultimately, the more classes that are like-named, the more classes would
have instable names from one release to the next as more duplicated names
are encountered.
What if instead JCC supported the original Java namespaces all the way to
the Python inteface (still dropping the original 'org.apache' Java package
tree prefix) ?
The world-rooted style of naming Java classes isn't Pythonic but using the
second half of the package structure feels right at home in the Python
world.
JCC already re-creates the complete Java package structure in C++ as
namespaces for all the C++ code it generates, for both the JNI wrapper
classes and the C++/Python types. It's only the installation of the class
names into the Python VM that is done in the flat 'lucene' namespace.
I think it shouldn't be too hard to change the code that installs classes to
create sub-modules of the lucene module and install classes in these
submodules instead (down to however many levels are in the original).
In other words:
- from lucene import Document
would become
- from lucene.document import Document
One could of course also say:
- import lucene.document.Document as whateverOneLikes
If that proposal isn't mortally flawed somewhere, I'm prepared to drop
support for --rename and replace it with this new Python class/module
layout.
Since this is being talked about in the context of a major PyLucene release,
version 4.0, and that all tests/samples have to be reworked anyway, this
backwards compat break shouldn't be too controversial, hopefully.
If it is, the old --rename could be preserved for sure, but I'd prefer
simplying the JCC interface than to accrete more to it.
What do you think ?
Andi..
Andi..
I can confirm the test_test_BinaryDocument.py crashes the JVM no more.
Roman
On Tue, Jul 10, 2012 at 8:54 AM, Andi Vajda <va...@apache.org> wrote:
Hi Roman,
On Mon, 9 Jul 2012, Roman Chyla wrote:
Thanks, I am attaching a new patch that adds the missing test base.
Sorry for the tabs, I was probably messing around with a few editors
(some of them not configured properly)
I integrated your test class (renaming it to fit the naming scheme used).
Thanks !
So far, found one serious problem, crashes VM -- see. eg
test/test_BinaryDocument.py - when getting the document using:
reader.document(0)
test/test_BInaryDocument.py doesn't seem to crash the VM but fails because
of some API changes. I suspect the crash to be some issue related to using
an older jcc.
I see a comment saying: "couldn't find any combination with lucene4.0
where
it would raise errors". Most of these unit tests are straight ports from
the
original Java version. If you're stumped about a change, check the
original
Java test, it may have changed too.
Andi..
