Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What if OpenDocument used SQLite? (2014)

sqlite.org

Post reply on HN
Print view View original

301–310 of 310 posts

Re: What if OpenDocument used SQLite? (2014)

#301

Post by anticensor »

dragonwriter wrote: post #286
bane wrote: post #285

Earlier quoted context omitted.

In other words, "all the implementors chose a standard, but we're the standard deciders so we're killing the whole idea".

One problem was the standard was bug-for-bug replication of a particular version of SQLite. There’s very good reason for that not to be a standard. (Now, assuming the SQLite documentation is licensed in a way which supports this, copying the documentation of SQLite’s supported SQL as of that version into the standard might have been viable, but no one interested in having WebSQL proposed that or any other resolution.…

SQLite itself is in the public domain.

Re: What if OpenDocument used SQLite? (2014)

#302

Post by rewmie »

torstenvl wrote: post #107
rewmie wrote: post #61

Earlier quoted context omitted.

> I can directly make the change in the database I don't need to have a model of the document other than its database format. I don't get your point. Are you saying that you don't need to have a model of the document other than the model of the document? What's the nuance I'm missing?

An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. Programmers often have to make software design decisions around how to represent a file in memory in order to manipulate it. For example, if I'm writing an HTML editor, should I mostly treat it like a text file (maybe a gap buffer) with syn…

> An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk.

The whole point of my remark is that the domain model and the export document format are two entirely separate things.

Re: What if OpenDocument used SQLite? (2014)

#303

Post by [deleted] »

p4bl0 wrote: post #242
remram wrote: post #76

Earlier quoted context omitted.

Why not use a transaction?

A single transaction for the whole user session? That seems a bad idea. Also I'm not sure you can do transactions during another transaction, and I need them for other purpose, i.e., for what they were designed to do (doing changes in multiple tables that need to stay consistent).

[deleted]

Re: What if OpenDocument used SQLite? (2014)

#304

Post by [deleted] »

rewmie wrote: post #302
torstenvl wrote: post #107

Earlier quoted context omitted.

An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. Programmers often have to make software design decisions around how to represent a file in memory in order to manipulate it. For example, if I'm writing an HTML editor, should I mostly treat it like a text file (maybe a gap buffer) with syn…

> An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. The whole point of my remark is that the domain model and the export document format are two entirely separate things.

[deleted]

Re: What if OpenDocument used SQLite? (2014)

#305

Post by [deleted] »

rewmie wrote: post #302
torstenvl wrote: post #107

Earlier quoted context omitted.

An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. Programmers often have to make software design decisions around how to represent a file in memory in order to manipulate it. For example, if I'm writing an HTML editor, should I mostly treat it like a text file (maybe a gap buffer) with syn…

> An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. The whole point of my remark is that the domain model and the export document format are two entirely separate things.

[deleted]

Re: What if OpenDocument used SQLite? (2014)

#306

Post by hddqsb »

fluidcruft wrote: post #185
didntcheck wrote: post #179

Earlier quoted context omitted.

> Not to mention that writing a single byte of content to a filesystems marks the entire blob as needing backup. If the size, mtime, and inode number stay the same (i.e. it writes into the file directly instead of replacing it), then most backup software will skip it. AFAIK to do otherwise you either need to read the whole file every time, or be live monitoring audit events to see what files have been opened for writ…

I am under the impression that modifying a file's content updates the modification time. Is this incorrect? Modifying a file without updating the mtime or allowing mtimes to be edited in userspace sounds like a security nightmare.

On Linux, the mtime ("modification time") is indeed automatically updated when the content is changed, but it can also be set arbitrarily from userspace (e.g. using `touch`) without special permissions. This is very useful, e.g. when you mirror a directory you'll typically want to preserve the mtimes, to help identify changes later.

Linux also has a ctime ("status change time"), which is automatically updated when the content or metadata (inode) are changed. It is not possible to change from userspace (you have to use tricks such as changing the computer clock or directly modifying the disk). This gives you the security benefits, but it is not commonly used e.g. in backup tools, precisely because they want to be able to set "fake" timestamps.

Re: What if OpenDocument used SQLite? (2014)

#307

Post by hddqsb »

mixmastamyk wrote: post #223
fluidcruft wrote: post #185

Earlier quoted context omitted.

I am under the impression that modifying a file's content updates the modification time. Is this incorrect? Modifying a file without updating the mtime or allowing mtimes to be edited in userspace sounds like a security nightmare.

Yes it does. mtimes can definitely be edited, if you have permission, but it is rare. I have a photo script that pulls the taken time from Exif and writes it to the file mtime.

> mtimes can definitely be edited, if you have permission

It just requires you to be the owner of the file (https://serverfault.com/a/337810), no special permissions. On the other hand, editing the ctime is not easy -- it requires tricks (e.g. change the computer clock, which typically requires root privileges).

Re: What if OpenDocument used SQLite? (2014)

#308

Post by hddqsb »

Tempest1981 wrote: post #214
gwbas1c wrote: post #135

I shipped a product that used both SQLite and XML files. One of the improvements that I made was moving a few tables that contained small amounts of data to xml files. Because these files were small and rarely written; it simplified the data access layer, and simplified diagnostics. (I made sure the files were multi-line tabbed xml.) For "technical" people who needed to diagnose the product, asking them to crack open…

I'm unclear on how SQLite (native format, no zip) is achieving sizes similar to XML + Zip. Are SQLite TEXT or BLOB fields compressed? Or are they assuming the caller is compressing BLOBs before writing?

The article assumes the caller compresses the blobs.

Re: What if OpenDocument used SQLite? (2014)

#309

Post by cxr »

justin66 wrote: post #206
nelgaard wrote: post #200

Earlier quoted context omitted.

But those are completely different uses of a storage format. Library of congress considers if someone a 100 years from now could write a new importer in whatever langauge/AI they might use by then. Office documents are something you send in email attachments to people you often barely know, and expect them to read it in whatever office system they have. And if the recipient uses e.g., Microsoft Word, OFD/Sqlite might…

It is true that it requires effort for the developers of a software program to support a given file format. Beyond that I'm not sure what your point is.

They're constrained by different requirements. The comment was clear enough:

"those are completely different uses"

It's not a hard concept to grasp. There is no riddle to decipher.

Re: What if OpenDocument used SQLite? (2014)

#310

Post by [deleted] »

rewmie wrote: post #302
torstenvl wrote: post #107

Earlier quoted context omitted.

An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. Programmers often have to make software design decisions around how to represent a file in memory in order to manipulate it. For example, if I'm writing an HTML editor, should I mostly treat it like a text file (maybe a gap buffer) with syn…

> An in-memory data model often differs from the serialized data as it exists on disk. For example, emacs uses a gap buffer for text files; but it outputs plain linear text to disk. The whole point of my remark is that the domain model and the export document format are two entirely separate things.

[deleted]
Post reply on HN