Change references to Error and Result -> ormlite::Error and ormlite::Result

[eboody]

When using the Model derive macro, user-land Error and Result conflict with ormlite's Error and Result.

I renamed them so that consumers of ormlite can have their own Result and Error in their crate's namespace.

[eboody]

I think it should be possible to have an ormlite::Error along with the derive Model macro but I think somewhere in the macro the unqualified Error and Result are being used and I dont know how to address that :/

@kurtbuilds

[eboody]

bump! this just uses more qualified paths so that when deriving Model the macro doesnt also use up the Result and Error in the userland namespace! So we dont have conflicting Error and Results

we can, when defining our own errors reference ormlite::Error

[eboody]

hey @kurtbuilds ! hope your move went well and youre settled in.

do you think these PRs are worthwhile? if you dont im happy to either talk about it or close the PRs!

[kurtbuilds]

Can you clarify what this PR is doing? I have plenty of code where I use a server::error::{Error, Result}, that has a Fromormlite::error::Error and corresponding result, and using the derive macros works fine.

[eboody]

@kurtbuilds

Yeah, if we create a new bare-bones project:

cargo new --lib demo
cd demo
cargo add ormlite -F "postgres"
cargo add sqlx

and add this to our lib.rs

#[derive(ormlite::Enum)]
pub enum Foo {
    Bar,
    Baz,
}

everything is fine.

If we make our lib.rs

type Result<T> = core::result::Result<T, Error>;

enum Error {
    A,
    B,
}

#[derive(ormlite::Enum)]
pub enum Foo {
    Bar,
    Baz,
}

then we get an error.

The reason being is ormlite's expansion has use crate::Result; which conflicts with a user-defined Result in the same namespace.

So this PR simply uses a more qualified path so that user's can have their own Result.