hi meikel so in your case after initial load of the knowledge-base there are no changes that need to be persisted, right ?
following stefan tilkovs book i want to do a simple RESTful order-management (exercise only) and think of using core.logic for query-logic. persisting changes to rdbms seems not a good idea in case the aim is to get rid of "OOM/Relational Model impedance mismatch" gruesse On Aug 5, 2:29 pm, "Meikel Brandmeyer (kotarak)" <m...@kotka.de> wrote: > Hi, > > Am Freitag, 5. August 2011 14:06:58 UTC+2 schrieb David Nolen: > > > Nope there's a not in the source to switch to refs and transactions. > > Woops. Indeed. I missed the comment. > > >> And a last question: Is this something like (or developed to or help > >> to move) contrib.datalog? > > > As far as I can tell core.logic can do almost everything > > contrib.datalog does. The main missing piece is stratified negation. > > I think for my use case of core.logic might already be sufficient. I work > with subcomponents which might be used various products. We get only these > final products back. And it is tedious to get the chain down from the final > product number to the subcomponent for various reasons which start with > sloppy user input and do not end with SAP. > > I think core.logic would really help me here. > > As for the concurrency story: I would read in facts at the program start. > But after that they'd remain static. So no issue here... > > Thanks for your awesome work on core.logic! > > Meikel -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
