Discussion:
Clojure.spec -> Datomic schemas?
Linus Ericsson
2016-06-08 08:08:32 UTC
Permalink
It seems quite obvious that clojure.spec data with some extra tagging could
be converted to Datomic schemas in a straight-forward manner.

There are obstacles ahead, though, given that clojure.spec can only be used
with yet-to-be-released Clojure 1.9.0.

Does the Datomic team have any masterplan, short term, for publicing such
work?

/Linus
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alan Moore
2016-06-09 07:05:52 UTC
Permalink
I have been looking into doing this but am still learning clojure.spec as completely as I can first. I would rather use something built by the Datomic team because they live and breathe this stuff and would do a much better job than me...

Baring that, I'm game to contribute to any community driven effort.

Take care.

Alan
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Stoner
2016-10-19 15:57:24 UTC
Permalink
I found this thread as I was googling, looking into exactly this question.
I did also see this:

https://github.com/SparkFund/spec-tacular

I'm not deep enough into any of this--Datomic, spec, or Clojure itself--to
judge this effort. I am curious what others think of it, though.
Post by Alan Moore
I have been looking into doing this but am still learning clojure.spec as
completely as I can first. I would rather use something built by the
Datomic team because they live and breathe this stuff and would do a much
better job than me...
Baring that, I'm game to contribute to any community driven effort.
Take care.
Alan
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Egg Syntax
2016-10-20 01:51:20 UTC
Permalink
We went the other way, and generated specs from our Datomic schemas for a
while (because we already had preexisting schema definition files). We
generated them from our more concise schema definition shorthand, actually;
in retrospect I wish I'd generated them directly from the schemas, because
then it would have been worth sharing the code with the community. Since
then we've decided to use a simple data model to describe our domain
concepts; we generate both spec and the schemas from that model, which is
definitely simpler in terms of parsing, because the models are quite
simple. Our models look like:

{:id :ti/Geography
:doc "A geographical area such as a country, state, city,
zipcode-region or zipcode"
:attrs {:id {:doc "A unique identifier for this geographical
area"
:type :uuid
:unique :identity}
...}}


In fact we've written specs for the models, so a lot of the parsing work
disappears because we can just use s/conform.

The generated specs aren't too much use as documentation, because as pulled
out of the registry they're not terribly readable, but the models are
pretty self-documenting, so it's not much of a shortcoming. We use the
specs for generating seed data, validation, and destructuring; eventually
we'll use them for generating tests as well. I'm pretty happy with our
current approach.
Post by John Stoner
I found this thread as I was googling, looking into exactly this question.
https://github.com/SparkFund/spec-tacular
I'm not deep enough into any of this--Datomic, spec, or Clojure itself--to
judge this effort. I am curious what others think of it, though.
Post by Alan Moore
I have been looking into doing this but am still learning clojure.spec as
completely as I can first. I would rather use something built by the
Datomic team because they live and breathe this stuff and would do a much
better job than me...
Baring that, I'm game to contribute to any community driven effort.
Take care.
Alan
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Christopher Small
2016-10-25 06:30:26 UTC
Permalink
I've been thinking about doing this as well. Would love to see a general
purpose solution. I'll share if I come up with something.
Post by Egg Syntax
We went the other way, and generated specs from our Datomic schemas for a
while (because we already had preexisting schema definition files). We
generated them from our more concise schema definition shorthand, actually;
in retrospect I wish I'd generated them directly from the schemas, because
then it would have been worth sharing the code with the community. Since
then we've decided to use a simple data model to describe our domain
concepts; we generate both spec and the schemas from that model, which is
definitely simpler in terms of parsing, because the models are quite
{:id :ti/Geography
:doc "A geographical area such as a country, state, city,
zipcode-region or zipcode"
:attrs {:id {:doc "A unique identifier for this geographical
area"
:type :uuid
:unique :identity}
...}}
In fact we've written specs for the models, so a lot of the parsing work
disappears because we can just use s/conform.
The generated specs aren't too much use as documentation, because as
pulled out of the registry they're not terribly readable, but the models
are pretty self-documenting, so it's not much of a shortcoming. We use the
specs for generating seed data, validation, and destructuring; eventually
we'll use them for generating tests as well. I'm pretty happy with our
current approach.
Post by John Stoner
I found this thread as I was googling, looking into exactly this
https://github.com/SparkFund/spec-tacular
I'm not deep enough into any of this--Datomic, spec, or Clojure
itself--to judge this effort. I am curious what others think of it, though.
Post by Alan Moore
I have been looking into doing this but am still learning clojure.spec
as completely as I can first. I would rather use something built by the
Datomic team because they live and breathe this stuff and would do a much
better job than me...
Baring that, I'm game to contribute to any community driven effort.
Take care.
Alan
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kenny Williams
2018-01-04 21:43:37 UTC
Permalink
Just happened upon this thread while debugging a tangential problem. We
wrote and have been using Spectomic <https://github.com/Provisdom/spectomic> at
my company for a while now. It transforms specs into Datomic schema using
generators.
Post by Christopher Small
I've been thinking about doing this as well. Would love to see a general
purpose solution. I'll share if I come up with something.
Post by Egg Syntax
We went the other way, and generated specs from our Datomic schemas for a
while (because we already had preexisting schema definition files). We
generated them from our more concise schema definition shorthand, actually;
in retrospect I wish I'd generated them directly from the schemas, because
then it would have been worth sharing the code with the community. Since
then we've decided to use a simple data model to describe our domain
concepts; we generate both spec and the schemas from that model, which is
definitely simpler in terms of parsing, because the models are quite
{:id :ti/Geography
:doc "A geographical area such as a country, state, city,
zipcode-region or zipcode"
:attrs {:id {:doc "A unique identifier for this
geographical area"
:type :uuid
:unique :identity}
...}}
In fact we've written specs for the models, so a lot of the parsing work
disappears because we can just use s/conform.
The generated specs aren't too much use as documentation, because as
pulled out of the registry they're not terribly readable, but the models
are pretty self-documenting, so it's not much of a shortcoming. We use the
specs for generating seed data, validation, and destructuring; eventually
we'll use them for generating tests as well. I'm pretty happy with our
current approach.
Post by John Stoner
I found this thread as I was googling, looking into exactly this
https://github.com/SparkFund/spec-tacular
I'm not deep enough into any of this--Datomic, spec, or Clojure
itself--to judge this effort. I am curious what others think of it, though.
Post by Alan Moore
I have been looking into doing this but am still learning clojure.spec
as completely as I can first. I would rather use something built by the
Datomic team because they live and breathe this stuff and would do a much
better job than me...
Baring that, I'm game to contribute to any community driven effort.
Take care.
Alan
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Isaac Zeng
2018-01-31 06:43:36 UTC
Permalink
I would recommend https://github.com/gfzeng/datomic.schema
Post by Linus Ericsson
It seems quite obvious that clojure.spec data with some extra tagging
could be converted to Datomic schemas in a straight-forward manner.
There are obstacles ahead, though, given that clojure.spec can only be
used with yet-to-be-released Clojure 1.9.0.
Does the Datomic team have any masterplan, short term, for publicing such
work?
/Linus
--
You received this message because you are subscribed to the Google Groups "Datomic" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datomic+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...