Earlier quoted context omitted.
... well, from the link... "Noms is supported on Mac OS X and Linux. You can compile a Windows build from source, and it usually works, but isn't officially supported." Also, supporting Windows is often a pain in the ass compared to Linux/Mac. I don't fault them for not supporting it officially, especially in the project's life.
To be fair, Mac support is also a huge pain, unless you happen to have a Mac. Just getting a machine to test on is expensive. If you look for Mac OS VMs in the cloud, you find they start at $1 an hour ( https://www.macincloud.com/ ) or around $80 / month ( http://xcloud.me/pricing-signup/ ). Compare that to around $5 / month for a Linux VM. And then you have to go the whole dance of getting xcode and homebrew just to…
Noms – A versioned, forkable, syncable database
81–90 of 107 posts
Re: Noms – A versioned, forkable, syncable database
#82Re: Noms – A versioned, forkable, syncable database
#83Weird choice for the uri: http://localhost:8000::dbname Why not http://localhost:8000/dbname ?
Re: Noms – A versioned, forkable, syncable database
#84Hi Hacker News. I'm one of the founders of the Noms project and Attic Labs, the company behind it. Happy to answer any questions. In the meantime, as long as I've got your attention, here's a few new stuffs we've been working on since last time Noms was discussed here in August: - A prototype query language, and a demo of how to create indexes in Noms: https://www.youtube.com/watch?v=fv6_T5yaWns - Support for merging…
There's quite a dramatic claim on the website, "merge [...] changes efficiently and correctly days, weeks, or years later." How does that work? For example if you have two records saying userid 3's name is "ann" and userid 3's name is "jane", I don't see how you could merge those without extra information or human input.
The world contains logical conflicts because physical constraints mean that processes can operate disconnected from each other. No database can wave that away.
Noms will automatically, efficiently, and correctly merge changes that don't logically conflict. Which is a pretty cool and unique property in a database.
If any conflicts are found, there is a callback to user software to perform a resolution.
More info in the documentation:
Re: Noms – A versioned, forkable, syncable database
#85Hi Hacker News. I'm one of the founders of the Noms project and Attic Labs, the company behind it. Happy to answer any questions. In the meantime, as long as I've got your attention, here's a few new stuffs we've been working on since last time Noms was discussed here in August: - A prototype query language, and a demo of how to create indexes in Noms: https://www.youtube.com/watch?v=fv6_T5yaWns - Support for merging…
Does/will Noms have proper support for multiuser sync? That’s an issue with CouchDB. I mean: instead of syncing whole the database, only syncing the parts that a user has access to, and being able to define those accesses. The standard use case for consumer apps.
So yes, in principle, we can definitely do this. In practice we are missing some conveniences that would make it a really easy drop-in feature.
Re: Noms – A versioned, forkable, syncable database
#86Hi Hacker News. I'm one of the founders of the Noms project and Attic Labs, the company behind it. Happy to answer any questions. In the meantime, as long as I've got your attention, here's a few new stuffs we've been working on since last time Noms was discussed here in August: - A prototype query language, and a demo of how to create indexes in Noms: https://www.youtube.com/watch?v=fv6_T5yaWns - Support for merging…
How do you deal with access control? I can imagine that it would be necessary in many applications to have parts of the database only accessible to some people, and that access rules could be complicated and also depend on values in the database itself.
Re: Noms – A versioned, forkable, syncable database
#87I really like this, I've always thought that git needed to support diff modes different from textline-based because even if this is fit for most programming languages what you really what is to see differences between ASTs (take into account those absurd change counts when just changing the indentation or imagine a normal diff of LISP source). Maybe there's some way of replacing git with noms to get there(even if it…
Re: Noms – A versioned, forkable, syncable database
#88I've been working on some syncing addressbook, calendar, password manager, and notes applications. My idea was to use mdns to announce presence and git to sync, but this might be (more) useful
Re: Noms – A versioned, forkable, syncable database
#89Hi Hacker News. I'm one of the founders of the Noms project and Attic Labs, the company behind it. Happy to answer any questions. In the meantime, as long as I've got your attention, here's a few new stuffs we've been working on since last time Noms was discussed here in August: - A prototype query language, and a demo of how to create indexes in Noms: https://www.youtube.com/watch?v=fv6_T5yaWns - Support for merging…
Do you have any plans to provide C/C++ bindings?
I created a bug for this just now: https://github.com/attic-labs/noms/issues/2718
Please feel free to get involved there.
Re: Noms – A versioned, forkable, syncable database
#90Earlier quoted context omitted.
There's quite a dramatic claim on the website, "merge [...] changes efficiently and correctly days, weeks, or years later." How does that work? For example if you have two records saying userid 3's name is "ann" and userid 3's name is "jane", I don't see how you could merge those without extra information or human input.
The claim on the website is not meant to suggest that any two changes can be automatically merged. I will try to clarify that. The world contains logical conflicts because physical constraints mean that processes can operate disconnected from each other. No database can wave that away. Noms will automatically, efficiently, and correctly merge changes that don't logically conflict. Which is a pretty cool and unique pr…