hnaderi / edomata Goto Github PK

Edomaton.transform is unnecessarily strict on transformation types

This somehow managed to escape from tests! fix and write more exhaustive tests.

skunk.exception.PostgresErrorException: 
🔥  
🔥  Postgres ERROR 42601 raised in scanner_yyerror (scan.l:1180)
🔥  
🔥    Problem: Syntax error at or near ",".
🔥  
🔥  The statement under consideration was defined
🔥    at /home/runner/work/edomata/edomata/modules/skunk/src/main/scala/Queries.scala:121
🔥  
🔥    update "account".outbox
🔥    set published = $1
🔥    where seqnr in ($2), ($3)
🔥                       └─── Syntax error at or near ",".
🔥  
🔥  If this is an error you wish to trap and handle in your application, you can do
🔥  so with a SqlState extractor. For example:
🔥  
🔥    doSomething.recoverWith { case SqlState.SyntaxError(ex) =>  ...}
🔥  

          Hi @hnaderi,

Thank you for your support! I think about integrating Edomata Event Sourcing model with a Bi-temporal Database like "XTDB". What do you think about it? There is no open-source FSM library that support bi-temporal sourcing and queries. Edomata could be best option to do this. Please help us with examples to develop Edomata with XTDB queries!!

Originally posted by @BNationsDEV in #108 (comment)

X tests.SkunkPersistenceKeywordNamespaceSuite.skunk: Must consume outbox correctly once failed in the CI

Current modules are compiled for scala 3. Scala 2 cross-compilation is necessary for Edomata.

It is a straightforward implementation based of already available skunk driver.

I look the existing example in the repo but I didn't quite understand. Also Tutorial documentation It's okay but I want to run these tutorial examples. For example

Released stuff in v0.7.0 are neither documented nor mentioned in tutorials.

This creates problems for namespaces that are SQL keywords, like order.

Its there, but is not used in the builder.

After #57 , we can split sql-backend module into 2 modules:

• backend which contains all common implementations and interfaces
• postgres which contains common postgres driver related implementations

This will allow to reuse backend implementations easily and implement new drivers more easily.

I'm using two ZIO scope blocks in my codebase one of them is for creating commands and the other for listening if an event published. When the command and the listener are in the same code block and run sequentially, there is no problem, but when they are run in different time intervals, the listening side does not receive information. How can I solve this?

There is a pub/sub mechanism or it's reading from the database?

Command code block like this example; https://github.com/hnaderi/edomata-example/blob/05609b7f54388dae89b9a925eea21b794db9fd39/core/src/main/scala/dev/hnaderi/example/Main.scala#L47

Listening code block

def mySink(app: Application[Task]) = ZSink.foreach((item: OutboxItem[Notification]) =>
  for {
    _ <- printLine("mySink: " + item)
    _ <- app.accounts.storage.outbox.markAsSent(item)
  } yield ()
)

def printOutbox(app: Application[Task]) = app.accounts.storage.outbox.read.toZStream().run(mySink(app))

ZIO.scoped {
 for {
   app <- Application[Task]().toScopedZIO
   _ <- printOutbox(app)
  } yield ()
 }..fork

Storage handling should be separate from backend
This will simplify implementing different storage drivers and backends and introduces right level of abstraction for raw data manipulation or migration like operations