Disclaimer: it's been a long time since I coded in Java, and I have no knowledge of this new record feature, but coming from clojure I would guess the answers to be:

1. You can't change a record after the fact because if you do it's no longer reliable, it's been tampered with :)

2. Yes, existing records only. You can always create a new record pointing to the old or any other record.

3. Hope not, would make it unpractical to handle verbose facts.

I guess clojure really twisted my mind ;)

Yes that's the only solution I have found to sync progress on iPad, Android, and linux. If any FOSS solution exists on all these platforms in order to sync position progress I'm all ears.

If you're only after a power adapter for your X1C6 + iPhoneX then this Anker device will certainly work. I would however wonder if you really need 100W power, 75W would seem sufficient.

Edit: if you plan to use a USB to lightning connector for your iPhone X then indeed the 100W is needed as apparently this device splits power evenly (50W+50W) between the two USB C. A comment however says it's not fast charging the iPhoneX when they are both used, so now I understand your dilemma.

And missiles

In a pyramidal society it all depends where you stand. Most people function from a partial narrative, biased towards some local/invented optimum. The higher you go in the pyramid, the more conscious evil you can find. And usually you can only go high in the pyramid because you have proven yourself capable of evil.

Yes and no. Lambs and eagles do not think, at least not like humans. Evil and taste are not thoughts for them, they are experiences. However evil and taste have their own existence in the human mind, separate from experience. And that's why humans can be manipulated by thoughts only, not just by experience.

Who in their right mind wants to send their offsprings to butchery in war? It can only happen if you first create meaning and justify the war (e.g. a clear danger worse than war) if you expect people to follow.

So the real issue here is how easy it is to manipulate humans, to make them act like robots programmed by mainstream media so eager to show us a danger and the difference between "us" and "them".

This does not mean there is no intentionality though. Is it really a coincidence if some weapon manufacturers invest in media companies? Is it a coincidence if the same source of finance feed both sides of a conflict?

That: GraphQL is a mechanism for clients to specify the data document they want, and for servers to specify the documents they can serve. Datalog, or SQL for that matter, is a mechanism to expose data within a database. The GraphQL data model must be geared towards the end client point of view, e.g. some internal IDs can be hidden. Datalog on the other hand exposes the internal model of a data store, which is domain driven not client driven. Also you do not want end client devices to have the full power of datalog or SQL on your database, or else be ready to always watch those crazy queries that bring your server down to a crawl. GraphQL at least provides an indirection point where you can apply some form of resource control.

Any particular reason you still need Todoist even though Joplin can also handle some To Dos?

I would definitely prefer an approach where schema is explicit and defined in a minimum number of places. RDBMS/SQL schema do let you define schemas, however an important aspect of how SQL handles schemas which links back to their inflexibility is how they're defined at the level of a table, meaning a (possibly ordered) set of attributes.

A more flexible approach as taken by Datomic is to define schemas at the level of attributes, meaning an entity (table) does not have a schema, only attributes do. This requires attribute names to be within namespaces which can certainly be seen as equivalent to table names, but they don't have to, namespaces could also refer to an entire domain/subdomain/org/whatever.

Defining schema at the level of attributes provides a greater level of flexibility because client only declare/specify/depend-on a partial schema that only lists the attributes it needs. It also helps avoiding the "place oriented programming" approach of result sets, whereby attributes must be in a certain order, and if one does not have a value, you have to introduce NULL values.

Some domains or projects require or work better with "soft" schemas, at least initially. I always wanted "dynamic relational" where columns are optional and "create on write" (except for "ID", which is needed for row uniqueness guarantee). If you query for a column that doesn't exist, instead of an error, you get a blank for that column (or null, depending on design decisions or settings).

But, one can gradually add rules as the requirements solidify. You can later add a rule that all rows of the Employee table must have a non-blank "last_name" column. You can have a rule/constraint that requires it for new rows, and perhaps have a "cleaning mode" to check existing rows. With enough rules/constraints, it acts pretty much like the current crop of RDBMS.

Dynamic relational could still use SQL, with some minor modifications to clarify intended compare types. (SQL has warts, but nothing better has arrived yet that's sufficiently better to justify tossing an established standard.)

It's not SQL versus No-SQL, it should be strong-typed SQL versus "soft" SQL. That way one doesn't have to toss all their SQL/RDBMS knowledge to get a dynamic RDBMS. The current dichotomy of choice is unnecessarily stark: it's either an RDBMS with SQL, or something very foreign. The No-SQL movement was driven by hardware & scaling needs, not query language needs.

If anyone is interested in starting up a dynamic relational company, I'd be glad to supply you with a draft spec for free.

You may have heard of it already, but if you haven't, I would recommend taking a look at RethinkDb: https://www.rethinkdb.com/docs/architecture/

It is a NoSQL Db, but has a lot of the features you're talking about. It doesn't have any form of "schema", but does allow for SQL style relational data. It definitely supports your "dynamic relational" data idea as stated above. The only issue is that any sort of data constraints need to be addressed at the outside of the Db itself.

Interesting, but the "outside" constraint processor issue could be a show-stopper. The "gradual tightening" of the DB is a key selling point of dynamic relational. Parts of it could be borrowed to make DR. And it's not clear how one queries it with SQL (or something very close). A translator layer would probably be needed.

Hmm I'm not familiar with Datomic but in SQL you can always break tables apart as it makes sense. NULL values are fine too if you've already decided that is a valid state in your schema but you can also use mapping tables instead of nullable columns.

>client only declare/specify/depend-on a partial schema that only lists the attributes it needs.

Can you describe what you mean here? It just sounds like specifying your selected columns to someone who is not familiar with the tool.

Datomic is stritcly more(than SQL) between both worlds, you have half of your schema in the database(attributes) and the other half in clojure code (integrity checks, constraints, some validations, etc...).

Any reference to the book you wrote?