Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Mardo Del Cid
@mardo
I think writing as less boilerplate as possible is the best option
It is really a IDE limitation, not really a framework one. However, a lot of people is using IntelliJ, so maybe the IDEA API approach is the best fit here. I’ll have a look when I have a chance
otherwise, as I said earlier, is not huge deal… it is just happening in the companion objects when defining the indexes (primary keys, keys, and so on…)
;)
Mardo Del Cid
@mardo
Ohhh….
then it is a bigger issue than I initially thought
yeah makes sense, when doing queries we need to access the props, and intellij can’t figure out the props
John Sullivan
@sullivan-
Could you let me know what you find out with the IDEA API? If we learn that that approach isn't going to work, then maybe we should move forward with the second approach
Mardo Del Cid
@mardo
Sure, I’ll give it a shot this evening and get back to you
John Sullivan
@sullivan-
Cool thanks!

when I look here, it is injecting into the class that gets annotated:

https://github.com/JetBrains/intellij-scala/blob/idea172.x/src/org/jetbrains/plugins/scala/lang/psi/impl/toplevel/typedef/MonocleInjector.scala

in which case, it produces a string such as "def foo: Foo = new Foo {}"

so i wonder what kind of string you need to produce to add code into the companion object?
John Sullivan
@sullivan-
wow @mardo , looks like that is going to be a lot of work.
Mardo Del Cid
@mardo
oohhh I see… Not sure about the string though
John Sullivan
@sullivan-
adding support for things like User.key and User.queryDsl probably wouldn't be that difficult
But adding User.props might be a bigger deal
Mardo Del Cid
@mardo
hmmm… as a second thought, if scalameta is in the roadmap, maybe we should consider just ignoring this until that migration?
John Sullivan
@sullivan-
that might make more sense
Mardo Del Cid
@mardo
On the other hand, this could very well be a show stopper for IntelliJ users, I mean I love my vim and can easily switch to that, but many people won’t like that
Not sure when scalameta will have all the features that longevity needs
John Sullivan
@sullivan-
Just checking that.. Here's the roadmap of the general feature - typechecking - that I need: scalameta/scalameta#604
So one thing we could do is add the def mprop[A](propName: String): Prop[User, A] described in the ticket, and clearly mark in the ScalaDocs that it is provided as an IDEA workaround, and will go away after migration to scalameta
Mardo Del Cid
@mardo
yeah, that makes sense
John Sullivan
@sullivan-
I think mostly this is what I will need for meta: scalameta/scalameta#609
which looks relatively close on the roadmap
i gotta keep my ears perked for the next meta release, and probably dust off my feat/meta branch when it comes out
@mardo do you want to spearhead this approach: implement the two-step workaround described in longevity issue 36, clearly marked as a workaround that will be phased out when we migrate to scalameta
I'm happy to support you every step of the way if you want to take it on
John Sullivan
@sullivan-
get scalameta on the board: longevityframework/longevity#37
Mardo Del Cid
@mardo
@sullivan- Yes, I’m happy to help with #37. Not sure how much knowledge do I need to have regarding longevity, but I’ll definitely give it a shot
John Sullivan
@sullivan-
you mean #36 ?
#37 is about replacing Scala macros with scalameta, somewhere down the line
John Sullivan
@sullivan-
#36 is about short term measures to address of IDEA support
Mardo Del Cid
@mardo
sorry, yes… I meant #36
John Sullivan
@sullivan-
u r awesome
Mardo Del Cid
@mardo
#37 is out of my league as for now :D
Haven’t done anything with scalameta/scalamacros still
John Sullivan
@sullivan-
just a heads up for readers, the IDEA support has moved to issue #38
.
Hey everyone! I wanted to let you know that I will be leaving on vacation the day after tomorrow. I won't be back until August 28th or so. My connectivity will be pretty spotty where I'm headed, so don't be dismayed if it takes me a while to get back to you.
Mardo Del Cid
@mardo
This message was deleted
Mardo Del Cid
@mardo
Hi @sullivan-, Is there a way to have an autoincremented (or autogenerated in case of mongo, for instance) ID for the domain models? I was looking how to just to reuse the database’s autogenerated ones
John Sullivan
@sullivan-
Hi @mardo, thanks for writing. Sorry it's taken me a while to get back to you; I've just gotten back from a long vacation and tons of stuff to catch up on.
So in my understanding, MongoDB with autogenerate an _id field if you don't supply one. At the moment, I kind of consider that a database concern, and not a domain model concern. I think you would run into trouble if you included an attribute named _id in your domain model.
You can always generate a UUID in the software, and incorporate that into your model, using e.g. java.util.UUID.randomUUID()
longevity supports UUID columns in your domain model
John Sullivan
@sullivan-
I wanted to support ObjectId as well, but the reason why I didn't, is because ObjectId class is provided by the MongoDB driver, which is an optional dependency, and the way longevity is currently written, it's pretty hard to support ObjectId columns without making the MongoDB driver a hard dependency. But, yeah, you can generate an ObjectId within the JVM which is pretty much guaranteed to be unique, and this would be the recommended approach.
Once I migrate some of the internals to shapeless, users will be able to use types like MongoDB's ObjectId without having to include that driver as a hard dependency - the user would just have to supply an implicit shapeless.Generic[ObjectId] - or something like that.