Hi! When trying to run docker-compose run --rm sbt sbt test I get the following error:
Get:3 http://deb.debian.org/debian stretch/main amd64 nodejs amd64 4.8.2~dfsg-1 [3440 kB]
E: Failed to fetch http://deb.debian.org/debian/pool/main/i/icu/libicu57_57.1-6+deb9u3_amd64.deb 404 Not Found
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?Any pointers for fixing this would be appreciated
Are you on a branch or working off of master?
@deusaquilus what about being able to define an explicit projection? I guess it's different in Slick where the building blocks are columns so you can map to/from tuples, Quill needs named case class fields... but then shouldn't it be possible to go lower level than that? Case class field names are a nice convenience but they don't seem like a good building block to build abstractions on top of
Typeclasses don't feel like the right tool for the job to me
Let me turn the question around though, why don't nested case classes work by default? You can probably give a more definitive answer, my guess would be:
(1) Some backends support nested data
(2) Just because a field is a case class doesn't mean it doesn't get mapped to a single field
(2) Just because a field is a case class doesn't mean it doesn't get mapped to a single field
(3) Since field names are usually significant, should the name of the field of the embedded case class just be ignored? That feels inconsistent. (As in,
class class Outer(field1: Int, ignoredName: SomeEmbeddedCaseClass))
Point (1) suggests that the behavior might be backend-dependent, but that might not be desired. Not sure.
Point (3) is not the biggest deal, but I could hear an argument that the column names might in some cases make sense to be a combination of the outer field name and the inner field name
For example given
case class Person(name: String) and case class Row(owner: Person) the field name would be owner_name
But in other cases that's not desirable
Again, if for such cases I don't have to rely on Quill guessing a bunch of stuff based on my field names, but I could have more explicit building blocks, like a first-class Column type, that I could build my own abstractions on top of (as I do in Slick), it would enable a lot of possibilities
Then by default Quill generates those Columns based on a class class' field names and types (and implicits for those types), but you could override that behavior
Hi all,
I'm trying to refactor the following dynamic query into a compile-time version:
val query = if (fetchingForward)
quote {
filterBy(criteria).sortBy(_.id)(Ord.desc)
}
else
quote {
filterBy(criteria).sortBy(_.id)(Ord.asc)
}I was trying the following:
val sortOrder: Ord[Int] = if (fetchingForward) Ord.desc else Ord.asc
val query = quote {
filterBy(criteria).sortBy(_.id)(lift(sortOrder))
}However, I'm getting the exception during macro expansion error. Any suggestion on how I can fix this? Cheers.
2 replies
Is it possible to override how quill decodes and encodes LocalDateTime fields? I have a custom implicit
MappedEncoding imported but it appears to be ignored (as it would be mapping to an ISO string but is still mapped to what looks like an epoch second in stead). Is there any extra configuration to override the dencoders for those types that Quill is already aware of?
(Obviously I'd be happy to PR it back upstream if I get it working)
@fishb6nes an approach is to make a newtype like https://github.com/estatico/scala-newtype or shapeless tagged type, and do the mappedEncoding with that type.
val date = quote{query[Object].map(d=>d.DateTimeP)}
Hello,
what is the current recommendation about what async context to use with Quill 3.6.0 for PostgreSQL and with Scala 2.13?
There are some alternatives, but
- quill-async-postgres seems to be discontinued and buggy,
- quill-jasync-postgres seems not to be the official replacement and
- quill-ndbc-postgres is still not released for 2.13 (#1727)
I would like to deprecate Quill Scala 2.11 Javascript. All JVM 2.11 modules will remain for now. Does anyone have critical use-cases for this library?
:point_up: January 6, 2021 2:11 PM
is there any way to reuse querySchema definitions. for example
case class Person(name: String, age: Int) extends Embedded
case class Unit(stuff:Int,person:Person)
val q = quote{querySchema[Person]("table",
_.name-> "NAMED",_.age->"MyAge")}
val m = ctx.run(query[Unit].filter(p => p.person.name == "John"))I would like to be able to use the schema defined for Person in the query defined for Unit either through implicits or combining 2 querySchemas
Table case class is
case class DailyOrgActivity(
orgId: UUID,
date: String,
nuggetId: UUID,
userId: String)want to filter between startTime and endTime which are both org.joda.time.Datetime
how to do that in easy and effectibve way.
Right now I am getting a List(string ) between these two dates and using.filter(activity => liftQuery(inDatesChunk).contains(activity.date))
but it is not a good way.
2 replies
@ashutosh-shirole Directly in Java I don't think so because it is based on macros that are ran by the Scala Compiler at compile time. You could instead write a java
interface with all the methods you need, returning java types and collections, and implement this interface in Scala using Quill. This should be possible.
Hi, there is a small PR of mine waiting for a review. It fixes an annoyance for MySQL users that have tables with many columns. Maybe it's not a very common problem, however as the changes are small, it would be awesome if it could get reviewed. Just updated the branch to the master. PR: getquill/quill#2041 Related issue: getquill/quill#1907