This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-02-07
Channels
- # announcements (2)
- # babashka (18)
- # beginners (45)
- # bristol-clojurians (1)
- # calva (2)
- # cider (8)
- # clara (8)
- # clj-kondo (4)
- # cljdoc (6)
- # clojure (69)
- # clojure-chennai (1)
- # clojure-dev (21)
- # clojure-europe (3)
- # clojure-gamedev (3)
- # clojure-india (1)
- # clojure-italy (4)
- # clojure-nl (5)
- # clojure-norway (1)
- # clojure-spec (7)
- # clojure-uk (70)
- # clojurescript (122)
- # cloverage (5)
- # cursive (2)
- # data-science (3)
- # fulcro (21)
- # graalvm (3)
- # graphql (14)
- # jackdaw (2)
- # jobs (2)
- # lumo (2)
- # malli (1)
- # mount (1)
- # off-topic (22)
- # re-frame (2)
- # reitit (5)
- # ring (7)
- # shadow-cljs (47)
- # spacemacs (11)
- # tools-deps (127)
- # vim (16)
- # xtdb (9)
In my ongoing effort to encourage the adoption of Clojure(Script) and Crux within my C#/.NET/SQL-Server organization, I have encountered push back on the data modeling and persistence front. Basically the push back goes like this: “We just design our classes and Entity Framework does the rest! We just right code like the following: public async Task<IEnumerable<Weighment>> TimeAsync( IDataContext context, DateTime inStart, DateTime inEnd, DateTime outStart, DateTime outEnd) { return await Task.Run(() => { return Persistence.Find(context, w => w.Inbound >= inStart && w.Inbound <= inEnd && w.Outbound >= outStart && w.Outbound <= outEnd); }).ConfigureAwait(false); }” Any thoughts on a response?
Hi @hairfire - I'll have a think and will attempt to form a good articulation. There's the data-first approach - working with data as-is rather than attempting to model reality with types and having to keep pace and deal with changes - I'll ask @malcolmsparks to weigh in also 🙂
I use to work with ORM frameworks such as Hibernate for Java, and so I feel I have some context to draw on. I'd be tempted though to show the alternative - how simple it could be if you're just persisting maps of data and then immediately being able to perform graph queries against it - without the need for boilerplate code which can be stubborn to make changes to. A side by side comparison - showing code, is preferable to getting into a drawn out debate, in my experience!
I've been stressing the schema-on-read, schema-on-write, incremental-schema, sparse-data and data-as-is benefits, and have been pleased with the recognition thereof. Their retorts have typically centered around the ability to use "standard C#" (e.g., x <= y) to define a predicate pre-condition and mutation, all within an implicit transaction that will fail if a stale condition occurs, and built-in one-to-many and many-to-many C# entity accessors. Personally, I've never used Entity Framework, or any ORM for that matter, but I can see the value in the features they describe. I'm intrigued by the idea of specifying data relationships via spec/edn, and creating something that will "generate" accessor functions for Crux.
Sorry I'm late to respond on this one - it's worth noting that we are already thinking heavily about schema within and across documents. JSON Schema is very promising as a long-term direction and such a language-agnostic approach has potential for enormous reach and longevity (certainly more so than a tightly-coupled platform-specific system)
Any choice is a trade-off, so if something is easy during development, most likely something else down the line will not. Also many things have been written and said against ORM as a system evolves, e.g. leakiness, fighting against the framework, trying to circumvent it, etc. Understanding how the system will evolve, and even spiking likely scenario, should help highlight some trade-offs. But first and foremost, a willingness to explore other ways is required.
Thanks @fmjrey, my I have heard some of my colleagues mention "fighting against the framework" and/or "trying to circumvent it".