Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 05 2018 17:44
    Travis Jacoby6000/sqlz (feature/#40-adjust-ast-to-support-fixpoint) errored (422)
  • Oct 05 2018 17:43

    Jacoby6000 on #40-adjust-ast-to-support-fixpoint

    Remove hack that doesn't work (compare)

  • Oct 05 2018 17:40
    Travis Jacoby6000/sqlz (feature/#40-adjust-ast-to-support-fixpoint) errored (421)
  • Oct 05 2018 17:38

    Jacoby6000 on #40-adjust-ast-to-support-fixpoint

    Update sbt to latestish version (compare)

  • May 03 2018 17:58
    Travis Jacoby6000/sqlz (series/0.4.x) still failing (420)
  • May 03 2018 17:56
    Travis Jacoby6000/sqlz (series/0.4.x) still failing (419)
  • May 03 2018 17:52

    Jacoby6000 on 0.4.x

    Update readme.md (compare)

  • May 03 2018 17:52

    Jacoby6000 on 0.4.x

    Update readme.md (compare)

  • Apr 23 2018 04:47
    Jacoby6000 closed #60
  • Apr 23 2018 04:47
    Jacoby6000 closed #63
  • Apr 23 2018 04:46
    Jacoby6000 commented #63
  • Apr 23 2018 04:46
    Jacoby6000 edited #63
  • Apr 23 2018 04:45
    Jacoby6000 closed #50
  • Feb 14 2018 01:21
    Travis Jacoby6000/sqlz (series/0.4.x) broken (418)
  • Feb 14 2018 01:09

    Jacoby6000 on 0.4.x

    Work on jdbc algebra (compare)

  • Dec 28 2017 22:18
    Travis Jacoby6000/sqlz@5288f2e (prepared-statements) passed (417)
  • Dec 28 2017 22:16
    Travis Jacoby6000/sqlz (series/0.4.x) passed (416)
  • Dec 28 2017 22:14

    Jacoby6000 on prepared-statements

    Add sub-project to build (compare)

  • Dec 28 2017 22:13

    Jacoby6000 on 0.4.x

    Rip scoobie sbt 1.0 Old docs are useless, too and 4 more (compare)

  • Dec 28 2017 22:13
    Jacoby6000 closed #71
Gavin Bisesi
@Daenyth
Maybe
Jacob Barber
@Jacoby6000
heh, nice
Gavin Bisesi
@Daenyth
Generally speaking I do know how many columns and mostly what type
but one axis in particular is a bit brutal in terms of query structure
can convert from a simple select/groupby/where into a subquery+join lateral
with joins to extra tables that are optional
and the stuff I'm getting via join can either be a column or result of some specific functions or the contents of a dynamic key from a json doc
sooo
The code is pretty much in FML state in python :D
oh and another brutal bit is that the tables I'm querying against can change :')
seems less of an issue for yours and more of an issue for doobie
Jacob Barber
@Jacoby6000
Yeah. Sounds like what would be best for you, is if I made my things work a little more nicely with direct JDBC access. Then you can use this for building your crazy JDBC queries, and doobie for everything else
Gavin Bisesi
@Daenyth
That does sound like where I'd need to end up
I could maybe make it all work with hlist result type
but I'm a month or two away from that codebase right now
Jacob Barber
@Jacoby6000
That would be the best solution, if you can find a way to do that without your code getting unruly.
Gavin Bisesi
@Daenyth
I'll keep all that in mind
I do kind of feel an urge to post sqlalchemy's DSL to scala now
could be made much more ergonomic
Jacob Barber
@Jacoby6000
Maybe. But really everything you're talking about doing is being limited by the driver, not by my AST. Scoobie could easily be leveraged to do what you want with minimal effort. If there's anything additional you want from the DSL, I/you can always add that in.
Gavin Bisesi
@Daenyth
ok
Jacob Barber
@Jacoby6000

For a taste of how ugly shapeless can get, here's how I used to handle Select Queries as a data structure:

object QuerySelect {
    def apply[Table <: HList, QueryProjections <: HList, QueryUnions <: HList, ComparisonParameters <: HList, MappedProjections <: HList, MappedUnions <: HList, Params <: HList](
      table: QueryProjection[Table],
      values: QueryProjections,
      unions: QueryUnions,
      filter: QueryComparison[ComparisonParameters],
      sorts: List[QuerySort],
      groupings: List[QuerySort],
      offset: Option[Int],
      limit: Option[Int]
    )(implicit
      mv: UnwrapAndFlattenHList.Aux[QueryProjection, QueryProjections, QueryProjectionUnwrapper.type, MappedProjections],
      mu: UnwrapAndFlattenHList.Aux[QueryUnion, QueryUnions, QueryUnionUnwrapper.type, MappedUnions],
      p: Combine4.Aux[Table, MappedProjections, MappedUnions, ComparisonParameters, Params],
      pl: ToTraversable.Aux[QueryProjections, List, QueryProjection[_ <: HList]],
      ul: ToTraversable.Aux[QueryUnions, List, QueryUnion[_ <: HList]]): QuerySelect[Params] =
        QuerySelect[Params](table, pl(values), ul(unions), filter, sorts, groupings, offset, limit, p.combine(table.params, mv(values), mu(unions), filter.params))

  }

  case class QuerySelect[Params <: HList] private (
    table: QueryProjection[_ <: HList],
    values: List[QueryProjection[_ <: HList]],
    unions: List[QueryUnion[_ <: HList]],
    filter: QueryComparison[_ <: HList],
    sorts: List[QuerySort],
    groupings: List[QuerySort],
    offset: Option[Int],
    limit: Option[Int],
    params: Params
  ) extends QueryExpression[Params] with QueryValue[Params]

As opposed to what it is now:

  case class QuerySelect[F[_]](
    table: QueryProjection[F],
    values: List[QueryProjection[F]],
    unions: List[QueryUnion[F]],
    filter: QueryComparison[F],
    sorts: List[QuerySort[F]],
    groupings: List[QuerySort[F]],
    offset: Option[Int],
    limit: Option[Int]
  ) extends QueryExpression[F] with QueryValue[F]
Gavin Bisesi
@Daenyth
but also I do like just writing library code
:P
Jacob Barber
@Jacoby6000
Me too XD
Gavin Bisesi
@Daenyth
also porting sqlalchemy would give me a little insight into how other people have solved a problem I'm unfamiliar with
Jacob Barber
@Jacoby6000
True
Porting typeless code in to a typeful world is non-trivial though. So you'll run in to many more problems than they did :smile:
Gavin Bisesi
@Daenyth
yup
I mean, it has types
just when the checks happen :D
Jacob Barber
@Jacoby6000
@Daenyth Yesterday I made some pretty big steps toward forming an interpreter that just produces instances of PreparedStatement
Gavin Bisesi
@Daenyth
Ohhhh!
That's exciting!
Jacob Barber
@Jacoby6000
The postgres driver is now completely seperated from the ANSI SQL generation, and there's currently an interpreter that will produce raw string queries (no prepared params in that, though.. dangerous.)
Creating one that can do prepared statements from here won't be terribly difficult
Gavin Bisesi
@Daenyth
Very cool!
Jacob Barber
@Jacoby6000
Just thought I'd let you know that progress is being made :)
Gavin Bisesi
@Daenyth
:+1:
Uros Nedic
@urosn
Hi, Do you have plans to develop Scoobie for Cassandra? What is advantage of Scoobie over plain SQL? Thanks!
Jacob Barber
@Jacoby6000

I'm not totally familiar with CQL, but I don't think there is any reason I couldn't support it. I'd have to do some research. The work going in to #40 right now would almost certainly need to be completed first though.

The advantage of using Scoobie is that you're not using a string to build queries. So if you have a typo and accidentally type "seletc" you get a compiler error rather than finding out at runtime.

It's also easier to compose queries when you're not having to worry about concatenating strings.

William Harvey
@harveywi
Hi! Is there any way to do a SELECT DISTINCT with the current AST? How about GROUP BY?
Jacob Barber
@Jacoby6000
GROUP BY can be dine via selectQuery groupBy p"my.column".<dir> where <dir> can be asc or desceg: p"my.column".asc
@harveywi ^
select distinct cannot be done yet.
William Harvey
@harveywi
@Jacoby6000 Thank you!
Jacob Barber
@Jacoby6000
I'm waiting to add more to the AST until #40 is resolved
#40 changes how basically all of scoobie works, much for the better.
I've been making lots of progress on it lately, but have been stopped until scala/scala#5744 is finished
I'm currently poking around the compiler :p