Richard Searle's Blog

Thoughts about software

Archive for October, 2013

annotate Datomic transaction to record side effect

Posted by eggsearle on October 13, 2013

Extends previous post to indicate how the transaction can be annotated to indicate the email was generated.

In the general form, this can capture any metadata required to describe process(es) that have been executed, decisions made, etc.

 

 

Posted in datomic, datomisca, Scala | Leave a Comment »

Datomic txReport and tracking changes via Datomisca queries

Posted by eggsearle on October 13, 2013

A common web site use case is notifying a user of a change of address, with notifications to both old and new addresses.
This is a simple mechanism that helps to address fraud.

Generally this code would form part of the http post action, perhaps including some indirection via a queue.
Arguably that logic is orthogonal to the primary function of the web site.

Datomic records all changes to entities and provides a notification mechanism

The following gist illustrates how this might be implemented.

Line 39 creates a user with the name “john” and email “jon@example.com”.
Line 44 updates that user, changing the email to “john@example.net”

Line 46 defines a query that will retrieve the name and previous email, given a delta to the user entity

Line 59 will print empty result since qe is the change that created the user (and there is thus no previous value)
Line 62 creates the result:(“john”, “jon@example.com”,”john@example.net”)
Which provides the name, before and after emails needed to send the warning email.

Posted in datomic, datomisca, Scala | Leave a Comment »

Unexpected attribute handling when querying datomic txReport

Posted by eggsearle on October 12, 2013

Perform queries with results indicated 
Peer.q(“[:find ?value :in $ :where [_ :db/doc ?value]]”,tx.get(Connection.TX_DATA)); //returns []
Peer.q(“[:find ?value  :in $ :where [_ :db/doc ?value]]”,db); //returns values
Peer.q(“[:find ?value  :in $ :where [_ 61 ?value]]”,tx.get(Connection.TX_DATA)); //returns values
Peer.q(“[:find ?value  :in $ :where [_ 61 ?value]]”,db); //returns values
 
So :db/doc is mapped to 61 for a query against the database but not when referencing the txReport.
This initially looks rather strange but is a direct consequence of how Datomic is implemented. 
:db/doc is merely an entity stored in the database, just like any other entity. It is not a special constant, baked into the implementation.
The txReport value does not contain the entity and thus cannot perform the mapping to attribute id. 
 
 
Set up the test
uri = “datomic:mem://hello”;
Peer.createDatabase(uri);
datom = Util.list(“db/add”,
                  Peer.tempid(“db.part/user”),
                  “db/doc”,
                  “hello world”);     
queue = conn.txReportQueue();
conn.transact(Util.list(datom)); 
db = conn.db();
tx=queue.poll();
 
 
 

Posted in Uncategorized | Leave a Comment »

datomic history

Posted by eggsearle on October 7, 2013

The history API returns a Database that contains asserts and retractions.

This seems to duplicate the Log API, so further study is required.

Posted in Uncategorized | Leave a Comment »

Query datoms via transaction id fails due to full scan error

Posted by eggsearle on October 6, 2013

The recent versions of datomic provide a  log interface that provides access to the transactions that have been processed.
That interface is unfortunately not implemented for memory databases, which complicates testing.

The datoms stored by Datomic are quads, which include the identity of the transaction.
It is thus possible to locate datoms asserted by a specific transaction

[:find ?e ?name  :in $ ?t  :where [ ?e :person/name ?name ?t]]

will locate all datoms that asserted a person’s name for a transaction id:t

One might then expect this would retrieve all the datoms asserted for a transaction

[:find ?e ?a ?v  :in $ ?t  :where [ ?e ?a ?v ?t]]

That query fails with “Insufficient binding of db clause: [?e ?a ?v ?t] would cause full scan”.

Which would make sense if datomic does not provide an index over transaction id.
However, it is not clear how the log interface can provide reasonable performance w/o that index.

 

 

 

Posted in Uncategorized | Leave a Comment »