Unable to build outside of crate

[mfpiccolo]

I was trying to set up another repo to play around with yaqb in another crate but I was unable to build the crate because of a cargo issue rust-lang/cargo#2064.

The error I am getting I think is due to conflicting libc's.

   Compiling yaqb v0.1.0 (file:///Users/mfpiccolo/code/mfpiccolo/yaqb_test)
/Users/mfpiccolo/code/mfpiccolo/yaqb/src/connection/mod.rs:320:23: 320:55 error: mismatched types:
 expected `*mut libc::types::common::c95::c_void`,
    found `*mut connection::libc::c_void`
(expected enum `libc::types::common::c95::c_void`,
    found enum `connection::libc::c_void`) [E0308]
/Users/mfpiccolo/code/mfpiccolo/yaqb/src/connection/mod.rs:320             PQfreemem(self.pg_str as *mut libc::c_void)

Are you able to use the crate as a dependency?

[mfpiccolo]

Update:

I could not get master to build locally on all three releases because of two libc mismatch types:

src/connection/mod.rs:267:13: 267:45 error: mismatched types:
 expected `u64`,
    found `usize`
(expected u64,
    found usize) [E0308]
src/connection/mod.rs:267             identifier.len() as libc::size_t,
                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/connection/mod.rs:267:13: 267:45 help: run `rustc --explain E0308` to see a detailed explanation
src/connection/mod.rs:320:23: 320:55 error: mismatched types:
 expected `*mut libc::types::common::c95::c_void`,
    found `*mut connection::libc::c_void`
(expected enum `libc::types::common::c95::c_void`,
    found enum `connection::libc::c_void`) [E0308]
src/connection/mod.rs:320             PQfreemem(self.pg_str as *mut libc::c_void)
                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I had to change line 276 of connection/mods.rs to use u64

-            identifier.len() as libc::size_t,
+            identifier.len() as u64,

And I had to comment out drop for PgString on line 317-323.

This is probably something that has to be solved on Cargo but in the mean time the repo can build by making the changes above.

[sgrif]

I think it's because I have a wildcard dependency on libc and they pushed a breaking change recently. I'll push up a fix shortly.

[sgrif]

Also sorry for the delay, I wasn't watching issues on this repo and didn't actually expect one to be opened!

[sgrif]

@mfpiccolo Fixed, sorry again for the delay. If you're actually trying to use this, let me know if I can help at all. I'm getting to the point where I should write up a usage guide and some docs, and having someone less familiar w/ the internals would be helpful for that.

[mfpiccolo]

@sgrif Thanks for pushing up the fix for the libc stuff. That is weird because I tried pulling down both yaqb and pq-sys and fixing the libc to '0.2.*' but was unable to get it to build. Not sure what I did wrong but this change worked. Also, did you release pq-sys 0.2.0 to crates.io without pushing the commit to github? I am guessing that you just locked the libc version there as well.

As for using the project, I am interested because I am writing a book on Rust for Manning that is focusing on learning Rust for programmers that only know high level languages (Ruby, JS, Python, etc). Mostly focusing on web stuff. Plus I really like Rust and want to start building a background job system in Rust for my consultancy.

Is this project going to be like AREL or will it also have the higher abstraction of an ActiveRecord-like ORM as well?

I would definitely be interested in helping out with the documentation or development.

[sgrif]

Also, did you release pq-sys 0.2.0 to crates.io without pushing the commit to github? I am guessing that you just locked the libc version there as well.

Yes on both. Just pushed.

Is this project going to be like AREL or will it also have the higher abstraction of an ActiveRecord-like ORM as well?

It's intended to be somewhere in between. Ultimately this is meant to be your persistence layer, but it's trending somewhere closer to the data mapper pattern. There's a lot of features that Active Record has that I don't think belong on the model layer, or are better handled by the database.

I've been porting crates.io to use this as something to give some amount of focus to get to 0.1. You can see where it's been heading here (note: there's a lot of noise and mess on that branch as well, I'm going to scrap 100% of that code if I ever do actually open a PR to port them over. This is just so I have a real world app to play with).

Off the top of my head WRT to changes from Active Record, the following come to mind:

• No thread local connection. If you're going to do stuff involving a database, you'll be taking &Connection as an argument
• Associations are non invasive. You won't have user.posts. If you want a user and all of its posts, then you'll get back a (User, Vec<Post>)
• Timestamps are just database triggers.
• The structs you use for updates and inserts can be (and almost certainly will be for insert) different types from the model you get back from select. So you tend to end up with create(conn: &Connection, new_user: &NewUser) -> Result<User, DbError>
• No model layer validations. Data integrity validations will be handled by the database (with some interface to display those to the UI if absolutely needed, such as unique indexes failing). Validating form input should get handled by the client or controller layers
• It's enforced that you use everything you select

I would definitely be interested in helping out with the documentation or development.

Wanna shoot me an email and we can coordinate further? It's on my github profile.