MyFavMirrors
/
moonfire-nvr
mirror of https://github.com/scottlamb/moonfire-nvr.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
moonfire-nvr/server/db/lib.rs

41 lines
1.2 KiB
Rust
Raw Normal View History

upgrade copyright notices * As discussed in #48, say "The Moonfire NVR Authors" at the top of every file rather than whoever created that file. Have one AUTHORS file listing everyone. * Consistently call it a "security camera network video recorder" rather than "security camera digital video recorder".
2020-03-02 01:53:41 -05:00
// This file is part of Moonfire NVR, a security camera network video recorder.
various doc improvements I bumped the minimum Rust version because I'm taking advantage of the rustdoc linking added in Rust 1.48: https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#easier-linking-in-rustdoc
2021-04-10 20:34:52 -04:00
// Copyright (C) 2021 The Moonfire NVR Authors; see AUTHORS and LICENSE.txt.
shorten per-file copyright headers I'm tired of all the boilerplate, so use the new GPL-3.0-linking-exception license identifier instead in all the server components. I left the ui stuff alone because I'm just going to replace it (#111). Add a checker for the header because it's easy to forget.
2021-02-17 16:28:48 -05:00
// SPDX-License-Identifier: GPL-v3.0-or-later WITH GPL-3.0-linking-exception.
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
various doc improvements I bumped the minimum Rust version because I'm taking advantage of the rustdoc linking added in Rust 1.48: https://blog.rust-lang.org/2020/11/19/Rust-1.48.html#easier-linking-in-rustdoc
2021-04-10 20:34:52 -04:00
//! Moonfire NVR's persistence layer.
//!
//! This manages both the SQLite database and the sample file directory.
//! Everything dealing with either flows through this crate. It keeps in-memory
//! state both as indexes and to batch SQLite database transactions.
//!
//! The core recording design is described in `design/recording.md` and is
//! mostly in the `db` module.
rustfmt everything I want to make the project more accessible by not expecting folks to match my idiosyncratic style. Now almost [1] everything is written in the "standard" style. CI enforces this. [1] "Almost": I used #[rustfmt::skip] in a few sections where I felt aligning things in columns significantly improves readability.
2021-02-17 01:15:54 -05:00
#![cfg_attr(all(feature = "nightly", test), feature(test))]
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
initial db layer work for authentication (#26)
2018-11-02 02:25:06 -04:00
pub mod auth;
update "moonfire-nvr check" for new schema
2018-03-01 20:07:42 -05:00
pub mod check;
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
mod coding;
schema comparison in new upgrade tests, "moonfire-nvr check" The .sql files here are copied from earlier revisions: v0.sql fee4141:src/schema.sql v1.sql 0d69f4f:src/schema.sql v3.sql 422cd2a:db/schema.sql
2019-07-11 11:07:40 -04:00
mod compare;
extract & generalize calendar day indexes My main goal is to support creating indexes for signals as well as recordings. An additional goal is to just shrink db.rs a bit; it's gotten quite large.
2021-03-23 12:40:52 -04:00
pub mod days;
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
pub mod db;
pub mod dir;
s/std::fs::read_dir/nix::dir::Dir/ in a few spots This is nicer in a few ways: * I can use openat so there's no possibility of any kind of a race involving scanning a different directory than the one used in other ways (locking, metadata file, adding/removing sample files) * filename() doesn't need to allocate memory, so it's a bit more efficient * dogfooding - I wrote nix::dir.
2019-07-12 14:05:36 -04:00
mod fs;
new docker-based build This replaces the previous Dockerfile, which was a single stage for building and deployment. The new one is a multi-stage build. Its "dev" target has the full development environment; its "deploy" target is more slim. It supports cross-compiled builds via BuildKit, eg to prepare a build suitable for a Raspberry Pi: docker buildx build --load --platform=linux/arm64/v8 --tag=moonfire-nvr --progress=plain --target=deploy -f docker/Dockerfile . Coming next: updating the installation docs.
2021-01-15 12:54:10 -05:00
mod proto {
include!(concat!(env!("OUT_DIR"), "/mod.rs"));
}
knob to reduce db commits (SSD write cycles) This improves the practicality of having many streams (including the doubling of streams by having main + sub streams for each camera). With these tuned properly, extra streams don't cause any extra write cycles in normal or error cases. Consider the worst case in which each RTSP session immediately sends a single frame and then fails. Moonfire retries every second, so this would formerly cause one commit per second per stream. (flush_if_sec=0 preserves this behavior.) Now the commits can be arbitrarily infrequent by setting higher values of flush_if_sec. WARNING: this isn't production-ready! I hacked up dir.rs to make tests pass and "moonfire-nvr run" work in the best-case scenario, but it doesn't handle errors gracefully. I've been debating what to do when writing a recording fails. I considered "abandoning" the recording then either reusing or skipping its id. (in the latter case, marking the file as garbage if it can't be unlinked immediately). I think now there's no point in abandoning a recording. If I can't write to that file, there's no reason to believe another will work better. It's better to retry that recording forever, and perhaps put the whole directory into an error state that stops recording until those writes go through. I'm planning to redesign dir.rs to make this happen.
2018-02-22 19:35:34 -05:00
mod raw;
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
pub mod recording;
new docker-based build This replaces the previous Dockerfile, which was a single stage for building and deployment. The new one is a multi-stage build. Its "dev" target has the full development environment; its "deploy" target is more slim. It supports cross-compiled builds via BuildKit, eg to prepare a build suitable for a Raspberry Pi: docker buildx build --load --platform=linux/arm64/v8 --tag=moonfire-nvr --progress=plain --target=deploy -f docker/Dockerfile . Coming next: updating the installation docs.
2021-01-15 12:54:10 -05:00
use proto::schema;
read-only signals support (#28) This is mostly untested and useless by itself, but it's a starting point. In particular: * there's no way to set up signals or add/remove/update events yet except by manual changes to the database. * if you associate a signal with a camera then remove the camera, hitting /api/ will error out.
2019-06-06 19:18:13 -04:00
pub mod signal;
move db upgrade logic into db crate This allows shrinking db's API surface.
2018-03-01 00:21:47 -05:00
pub mod upgrade;
tests and fixes for Writer and Syncer * separate these out into a new file, writer.rs, as dir.rs was getting unwieldy. * extract traits for the parts of SampleFileDir and std::fs::File they needed; set up mock implementations. * move clock.rs to a new base crate to be accessible from the db crate. * add tests that exercise all the retry paths. * bugfix: account for the new recording's bytes when calculating how much to delete. * bugfix: when retrying an unlink failure in collect_garbage, we shouldn't warn about all the recordings no longer existing. Do this by retrying each step rather than the whole procedure again. * avoid double-panic scenarios, which I hit while tweaking the mocks. These are quite annoying to debug as Rust doesn't print information about either panic. I ended up using lldb to get a backtrace. Better to be cautious about what we're doing when already panicking. * give more context on raw::insert_recording errors, which I hit as well while tweaking the new tests.
2018-03-04 15:24:24 -05:00
pub mod writer;
initial split of database to a separate crate It should reduce compile time / memory usage to put quite a bit of the code into a separate crate. I also intend to limit visibility of some things to only within the db crate, but that's for a future change. This is the smallest move that will compile.
2018-02-21 02:15:39 -05:00
// This is only for #[cfg(test)], but it's also used by the dependent crate, and it appears that
// #[cfg(test)] is not passed on to dependencies.
pub mod testutil;
upgrade to 2018 Rust edition This is mostly just "cargo fix --edition" + Cargo.toml changes. There's one fix for upgrading to NLL in db/writer.rs: Writer::previously_opened wouldn't build with NLL because of a double-borrow the previous borrow checker somehow didn't catch. Restructure to avoid it. I'll put elective NLL changes in a following commit.
2018-12-28 13:21:49 -05:00
pub use crate::db::*;
add concept of user/session permissions (I also considered the names "capabilities" and "scopes", but I think "permissions" is the most widely understood.) This is increasingly necessary as the web API becomes more capable. Among other things, it allows: * non-administrator users who can view but not access camera passwords or change any state * workers that update signal state based on cameras' built-in motion detection or a security system's events but don't need to view videos * control over what can be done without authenticating Currently session permissions are just copied from user permissions, but you can also imagine admin sessions vs not, as a checkbox when signing in. This would match the standard Unix workflow of using a non-administrative session most of the time. Relevant to my current signals work (#28) and to the addition of an administrative API (#35, including #66).
2019-06-19 18:17:50 -04:00
pub use crate::schema::Permissions;
read-only signals support (#28) This is mostly untested and useless by itself, but it's a starting point. In particular: * there's no way to set up signals or add/remove/update events yet except by manual changes to the database. * if you associate a signal with a camera then remove the camera, hitting /api/ will error out.
2019-06-06 19:18:13 -04:00
pub use crate::signal::Signal;