Add derive macro for View

[ecton]

• Blocked by Split schema traits into metadata and implementations #99

Once we split View implementations from their metadata, View could be derived in a similar fashion as #138.

The macro needs to be able to have the location of bonsaidb_core specified as an optional attribute. By default, it should use ::bonsaidb::core as the path to bonsaidb_core, but a user should be able to override it based on their usage. E.g., #[view(core = bonsaidb_server::core)].

[ModProg]

I you propose some attributes and implementation details, I'll implement the macro.

[ecton]

Yes, please!

#[derive(View)]
#[view(collection(CollectionType), key(KeyType), value(ValueType), name = "by-name", version = 0)]
struct MyView;

impl View for MyView {
  type Collection = CollectionType;
  type Key = KeyType;
  type Value = ValueType;

  fn name(&self) -> Name {
    Name::new("by-name")
  }

  fn version(&self) -> u64 {
    0
  }
}

• Require collection + key
• If name isn't specified, stringify the target type name (MyView in this example)
• If version isn't specified, don't implement the function.
• If value isn't specified, use ()

[ModProg]

bonsaidb/crates/bonsaidb-core/src/schema/view.rs

Lines 60 to 126 in aad8650

	pub trait View: Send + Sync + Debug + 'static {
	/// The collection this view belongs to
	type Collection: Collection;
	/// The key for this view.
	type Key: Key + 'static;
	/// An associated type that can be stored with each entry in the view.
	type Value: Send + Sync;
	/// The name of the view. Must be unique per collection.
	fn name(&self) -> Name;
	/// The namespaced name of the view.
	fn view_name(&self) -> ViewName {
	ViewName {
	collection: Self::Collection::collection_name(),
	name: self.name(),
	}
	}
	}
	/// The implementation of Map/Reduce for a [`View`].
	///
	/// See the [user guide for a walkthrough of how views
	/// work](https://dev.bonsaidb.io/guide/about/concepts/view.html).
	pub trait ViewSchema: Send + Sync + Debug + 'static {
	/// The view this schema is defined for.
	type View: SerializedView;
	/// If true, no two documents may emit the same key. Unique views are
	/// updated when the document is saved, allowing for this check to be done
	/// atomically. When a document is updated, all unique views will be
	/// updated, and if any of them fail, the document will not be allowed to
	/// update and an
	/// [`Error::UniqueKeyViolation`](crate::Error::UniqueKeyViolation) will be
	/// returned.
	fn unique(&self) -> bool {
	false
	}
	/// The version of the view. Changing this value will cause indexes to be rebuilt.
	fn version(&self) -> u64 {
	0
	}
	/// The map function for this view. This function is responsible for
	/// emitting entries for any documents that should be contained in this
	/// View. If None is returned, the View will not include the document. See [the user guide's chapter on
	/// views for more information on how map
	/// works](https://dev.bonsaidb.io/guide/about/concepts/view.html#map).
	fn map(&self, document: &Document) -> ViewMapResult<Self::View>;
	/// Returns a value that is produced by reducing a list of `mappings` into a
	/// single value. If `rereduce` is true, the values contained in the
	/// mappings have already been reduced at least one time. If an error of
	/// [`ReduceUnimplemented`](crate::Error::ReduceUnimplemented) is returned,
	/// queries that ask for a reduce operation will return an error. See [the
	/// user guide's chapter on views for more information on how reduce
	/// works](https://dev.bonsaidb.io/guide/about/concepts/view.html#reduce).
	#[allow(unused_variables)]
	fn reduce(
	&self,
	mappings: &[ViewMappedValue<Self::View>],
	rereduce: bool,
	) -> Result<<Self::View as View>::Value, crate::Error> {
	Err(crate::Error::ReduceUnimplemented)
	}
	}

It seems that version is in ViewSchema, but I don't think you would be able to derive the map function?

[ecton]

You're right, I typed that example from memory and I forgot what was where. Version is indeed for the schema portion of the trait.

ViewSchema I don't think will be derivable. We may want some sort of DSL-like macro to cut down some boilerplate, but I'll put in another issue to ponder that idea.

[ModProg]

So what is the state here, should this be closed? did you create a new issue for:

ViewSchema I don't think will be derivable. We may want some sort of DSL-like macro to cut down some boilerplate, but I'll put in another issue to ponder that idea.

[ecton]

Well, funny enough last night I realized I need to move version back to View.

But regardless, the macro can be implemented as-is without the version argument if it's not back on View at the time of implementation.

[ModProg]

Well, funny enough last night I realized I need to move version back to View.

But regardless, the macro can be implemented as-is without the version argument if it's not back on View at the time of implementation.

Yeah, and adding the version in is a 2-minute change, that anyone could quickly do!

[ecton]

I'm going to go ahead and consider this fully resolved -- the other tickets can handle the other requests for new/updated macros as needed.