lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Wed, 09 Aug 2017 08:08:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119549#comment-16119549
] 

ASF GitHub Bot commented on LUCENENET-565:
------------------------------------------

Github user jeme commented on the issue:

    https://github.com/apache/lucenenet/pull/209
  
    Ok so I think I will give up on commenting on all of the above because there is to much.
I will as a general note say be careful that you don't get ahead of your self.
    
    I personally think it would be a bad idea to put to much of all that AspNetCore, Owin
etc. into this particular project (project as Lucene in a whole, not each csproj file)...
    
    Instead I would separate them out and give them meaningful project names... and give them
their own release cycle...  (Actually I think the Lucene.Net.Replicator.AspNetCore project
would belong in one of those "child projects", but that is a bit complicated as it's currently
needed for tests, it might be possible to write the tests differently without it or add a
minimalistic implementation into test instead)
    
    They could still be under "Lucene.Net" organisation wise, but I think there would be many
advantages in allowing them to have their own repo and life...
    
    This would focus this repository on the port of lucene (as direct as possible, but also
to support these projects) and each project could have it's individual focus... (Lucene on
AspNetCore for all AspNetCore integration on different levels, Lucene on Nancy for that etc.)...
    
    Also, your already on the edge of making some decisions that would be bad for larger scale
projects... E.g. making a Singleton LuceneWriter (registered in a IoC Container or not) wouldn't
that limit you to only having a single index?... that would seem like an odd direction to
consider within this context as the Replicator directly supports shards... (aka multiple indexes?)
    
    It also seems that as things are right now you can't release each individual csproject
on it's own from here?... (E.g. releasing just the Lucene.Net package and not the rest?)...
If that is the case then I think that speaks even more for putting these more "platform" specific
integrations into their own project/repo/release cycle so they are not bound by each other...
So that these packages could be release on a much more rapid cycle than Lucene.Net it self.

    
    There is ofc. many considerations around such "branching out", but from having done so
quite a few time my self on our own projects, I can say that it is so much more convenient
in the long run...
    
    As a final note, I won't be able to find time to take the Lucene.Net.Replicator.AspNetCore
project much further, my goal was to focus on Lucene.Net.Replicator it self and provide a
meaningful port of that that could be integrated into AspNetCore (which we haven't even adopted
yet), AspNet4x, Nancy or similar frameworks with relative ease...
    
    Which path you take with Lucene.Net.Replicator.AspNetCore is up to you... But I don't
feel right about building anything two involved for a framework/platform I don't even use
and therefore don't know all the ins and outs of...
    
    To me it was an example integration that could help me find points in the Lucene.Net.Replicator
which might cause difficulty when integrating or straight out felt wrong and there are a few
things about the ReplicatorService that annoys me in that regard, but there is a broader picture
as the HttpReplicator aligns to that same theme and then there is your desire to stay compatible
with Java versions, which is questionably because they choose to actually serialize Exception
objects, if java clients expect any meaning of that then we are not compatible at all as all
Exceptions would end up as "Unknown Exceptions" in a Java client... and that goes for the
other way around as well...
    
    I do have a small super simplistic and extremely crude DEMO AspNetCore app that indexes
and publishes data and then a Console client that pulls the replicas which works. I am trying
to use this to weed out annoyances. 


> Port Lucene.Net.Replicator
> --------------------------
>
>                 Key: LUCENENET-565
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-565
>             Project: Lucene.Net
>          Issue Type: Task
>          Components: Lucene.Net.Replicator
>    Affects Versions: Lucene.Net 4.8.0
>            Reporter: Shad Storhaug
>            Priority: Minor
>              Labels: features
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message