Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 11 17:44

    mergify[bot] on master

    Update logback-classic to 1.2.7 Merge pull request #155 from sc… (compare)

  • Nov 11 17:44
    mergify[bot] closed #155
  • Nov 11 17:42
    scala-steward opened #155
  • Nov 03 19:56

    nafg on master

    Update scala-library, scala-ref… Regenerate workflow with sbt-gi… Merge pull request #153 from sc… (compare)

  • Nov 03 19:56
    nafg closed #153
  • Nov 02 18:37

    mergify[bot] on master

    Update scalameta to 4.4.30 Merge pull request #154 from sc… (compare)

  • Nov 02 18:37
    mergify[bot] closed #154
  • Nov 02 18:34
    scala-steward opened #154
  • Nov 01 17:22
    scala-steward opened #153
  • Oct 18 21:15
    mergify[bot] closed #152
  • Oct 18 21:15

    mergify[bot] on master

    Update scalameta to 4.4.29 Merge pull request #152 from sc… (compare)

  • Oct 18 21:13
    scala-steward opened #152
  • Oct 06 19:37

    mergify[bot] on master

    Update sbt-scalajs, scalajs-com… Merge pull request #151 from sc… (compare)

  • Oct 06 19:37
    mergify[bot] closed #151
  • Oct 06 19:36
    scala-steward opened #151
  • Oct 05 00:22

    nafg on master

    Update scala-library, scala-ref… Regenerate workflow with sbt-gi… Merge pull request #148 from sc… (compare)

  • Oct 05 00:22
    nafg closed #148
  • Sep 18 00:19

    mergify[bot] on master

    Update scalatest to 3.2.10 Merge pull request #150 from sc… (compare)

  • Sep 18 00:19
    mergify[bot] closed #150
  • Sep 18 00:17
    scala-steward opened #150
Peter Hancox
@phancox
Gave up and took the easy option; hardcoding just the databases I need
val profile = dbmsName match { case "PostgreSQL" => PostgresDriver case "H2" => new slick.driver.H2Driver with KeyedTableComponent case _ => new JdbcProfile with KeyedTableComponent }
val profile = dbmsName match { case "PostgreSQL" => PostgresDriver case "H2" => new slick.driver.H2Driver with KeyedTableComponent case _ => new JdbcProfile with KeyedTableComponent }
val profile = dbmsName match { case "PostgreSQL" => PostgresDriver case "H2" => new slick.driver.H2Driver with KeyedTableComponent case _ => new JdbcProfile with KeyedTableComponent }
val profile = dbmsName match { case "PostgreSQL" => PostgresDriver case "H2" => new slick.driver.H2Driver with KeyedTableComponent case _ => new JdbcProfile with KeyedTableComponent }
Peter Hancox
@phancox
OK I give up, just cannot get the formatting to hold using triple back-tick and shift-Enter for line breaks !
Peter Hancox
@phancox
@nafg Still trying to figure out the issue with inserts occurring twice. I've put together http://scastie.org/11285 which should demonstrate the issue but I can't get the scastie to run. Was intermittently complaining about issues finding the slick-additions jar but now just seems to hang.
I suspect the issue occurs when inserting a table that doesn't have relations to another table. The Scala is a bit above my level so it's taking a while to debug. The code I'm looking at is in KeyedTableComponent.insert where it has specific code for handling child lookups.
nafg
@nafg
@phancox any idea why it's not resolving?
Weird, I took out the explicit slick dependency (it should be pulled in transitively anyway), now it got past resolving and it has compile errors:
@phancox
Mmm, fixed those http://scastie.org/11295
and get
Caused by: java.lang.SecurityException: ("java.lang.RuntimePermission" "accessClassInPackage.sun.misc")
nafg
@nafg
Mmm, seems AbstractPromise calls scala.concurrent.util.Unsafe which tries to access something in sun.misc
I wonder what
@phancox any chance you could submit a PR on the repo that adds a failing unit test that demontrates the problem. Travis will run it, and it will be a useful unit test
Peter Hancox
@phancox
@nafg Presume you meant a PR on the scastie repo not on slick-additions? When I was running it last night (Sydney time) it seemed to be returning quite weird results. The only reason I put in the slick dependency was because it seemed to fix other errors I was having. Then I got errors with DefaultPromise, then errors with slick-additions not being found. And eventually it just stalled during the compile.
@nafg Any thoughts on whether trying to insert into a table without any child relations might be causing the insert to be applied twice?
nafg
@nafg
@phancox I meant on slick-additions. My understanding is you suspect it's a bug in slick-additions, in which case it would be good to have a test case for it in slick-additions to help fix the bug and prevent it from recurring.
In general a table shouldn't need relations to insert, but I don't have much context
Peter Hancox
@phancox
OK will do that in the next couple of days.
Peter Hancox
@phancox
@nafg Submitted a pull request.
nafg
@nafg
@phancox thanks! Will have to look at it when I get a chance
Matthew Pocock
@drdozer
There are plans. There is already a broken version one export. Can't talk - at a con
nafg
@nafg
@drdozer what?
nafg
@nafg
@phancox I found the problem, with G-d's help
      val v2 = k2 flatMap (updateAndSaveLookupLenses(_, e.value))
      for(k <- k2; v <- v2) yield SavedEntity(k, v)
Since v2 is flatMapped from k2, v2 has the INSERT operation from k2 in it already. Then in the for comprehension it flatMaps with k2 again.
Instead v2 should be a DBIO[(K, V)]
Peter Hancox
@phancox
@nafg Thanks for the update. However, I don't understand what has to change to make things work correctly?
nafg
@nafg
@phancox basically it needs to be
val e2 = k2 flatMap { k => (k, updateAndSaveLookupLenses(k, e.value)) }
for((k, v) <- e2) yield SavedEntity(k, v)
or better yet,
for {
  k <- k2
  v <- updateAndSaveLookupLenses(k, e.value)
} yield SavedEntity(k, v)
Peter Hancox
@phancox
@nafg Thanks; I find suggestion two easier to understand.
nafg
@nafg
Yes, the point of # 1 is it's more similar to current code, so it highlights the error better
I agree # 2 is a better way to actually do it
@phancox I see your pull request actually does a few things, like fix the before/after not Awaiting
Any chance you could split each thing into its own PR?
Peter Hancox
@phancox
OK but give me a bit of time; that was my first PR so I'm just learning some of this stuff. Do you want me to create one PR with both fix and test? Plus one for the before/after waits?
nafg
@nafg
Yeah I guess, sounds good
The before/after one could come first
Was there anything else you did?
Peter Hancox
@phancox
My tests would fail with a URL of "jdbc:h2:test". Had to make it a specific location for the DB "jdbc:h2:~/test". This didn't happen before I started making changes; think it had something to do with introducing the DB wait? Quite weird, I will try again without the change if you like?
nafg
@nafg
Ah
Well if the change is necessary for some unrelated reason, then it should be a separate PR. But it seems odd.
The only difference is whether the file is in the current directory or the home directory.
Peter Hancox
@phancox
@nafg Your original tests run fine until I change the before/after functions to wait on the future. Then tests throw
org.h2.jdbc.JdbcSQLException: A file path that is implicitly relative to the current working directory is not allowed in the database URL "jdbc:h2:test". Use an absolute path, ~/name, ./name, or the baseDir setting instead. [90011-187]