there is no real reason why we can't use lucene to do the "who references me" style questions... no need to re-type check anything. Every time a file is edited, we rebuild the index for that file.
@aemoncannon I'm currently looking at search and it seems that Lucene is only being used for indexing the binary classfiles. Does that mean we don't get search if our own source code hasn't been compiled yet?
I'd like to use Lucene to cache a lot of useful information that the presentation compiler can provide us about our own source code. Are you aware of any callback interfaces? e.g. for when it hits classes, traits, methods or (ideally) references to other symbols.
aah, I just found the callbacks in RichPresentationCompiler. It's all very much about symbols... we're missing the other information. Also, there doesn't seem to be anything about the references to a symbol, just the definitions? (or am I reading this wrong). I'll stick some logging around this and play some more tomorrow.
this might be dropped from 1.0 unless it turns out to be easy to implement
(Adding myself to this since issue since I'm looking into the db stuff.)
w00t! I should imagine it will dramatically increase the DB size so any thoughts on optimising the storage would be well received (although I suspect having a good filter on which symbols we care about... i.e. not java.lang.* or any anonymous classes) would be good enough.
FYI when we call this method https://github.com/ensime/ensime-server/blob/master/core/src/main/scala/org/ensime/indexer/ClassfileIndexer.scala#L17 we get handed the FQNs of everything in that file.
@cvogt you should know that @tpolecat is putting together a patch to move us to Doobie and he has threatened to look into this 😄 It's also on my personal hitlist soonish if he doesn't get to it.
@fommil @tpolecat no problem. I like what @tpolecat is doing. I am trying to excite people about type-safe composable queries :), but I also like doobie's free monad. Seems a bite more elaborate than slick's.
I should have more time to work on this next month.
I don't really like the scalaz functional style because I find it confuses more than helps, plus is a massive source of object creation / GC overhead. However, in this instance, the benefit is moving away from Slick (which I've now labeled as dirty until FreeSlick is ready) and getting back to raw SQL queries, which were causing compiler warnings in Slick. Hopefully @tpolecat can show us why free monads are useful, but I suspect we'll want all that to be contained to the DAO as implementation details.
although it is pretty awesome that we now have two of the Scala community's top DB contributors able to help on this 😀 so whatever happens I'm sure we'll have a rock solid implementation.
Is there any chance of an NIO implementation of the JDBC driver for H2?
Was it implemented in #1602 ?
@t3chnoboy no, that's something else, but the graph branch now stores the necessary information.
is this still WIP?
@olkinn I think so, waiting on #1681
Heh, yeah it's taking us forever to get the graph branch merged... we've had bad CI reliability problems hopefully now fixed. We'll probably do Scala 2.12 first since it's easier
It's coming... eventually :)