Hi Zach, David, some questions/observations: - Would this mean that we have to write all that type/spec stuff in model code? I love how simple it is to write model modules right now. In fact this is one of the great things about CB all round, explicit naming conventions, you know where you are.
- I think a degree of DB portability is important, it feels anecdotally from the posts here that people use a fair few different DBs. I think some NoSQL options are important. Personally I really want to keep TokyoTyrant as it's blazing fast and low maintenance. - Will these changes break existing code? I had to peg an existing project at boss_db version at v0.8.9 because the 0.8.9a version broke some stuff, it'd be really good to try to keep the API as much as possible. - I'm guessing you mean the parse transform stuff and the underlying boss_db code is hard to work with and 'not very erlangish'? Personally I've found the boss_db API to be pretty straightforward - I'm no erlang whiz, but I get real value from CB, and I think keeping it simple and straightforward for new users to understand is important for widening CB usage/popularity. Cheers, Igor On Wednesday, January 29, 2014 9:37:12 AM UTC-5, David Welton wrote: > > > I have been working on the inner bits of boss_db of late, you may have > seen > > a lot of commits come across that project. However I really want to > change > > the way that Models work. The current version relies on a lot of "Magic" > in > > the form of parse transforms. I dislike this for several reasons. > > > The transform code is a very hard to work with > > It makes it much harder to understand what your code is doing > > It creates a bunch of functions that have no source code, so they are > hard > > to understand > > it does not feel very "erlangish" in style. > > +1 to that. The trick is to replace them with something that is still > fairly easy to use, and perhaps make it more flexible too (and, as > they say, I'd like a pony, while we're at it:-) One of the things I > love about Ruby is how easy it is with Rails to string together some > fairly complex DB queries. You can actually do quite a bit before you > have to give up and just run raw SQL queries. > > > What I am proposing is that we change models to be a behavior, to create > a > > model you would just create a model that implemented the gen_model > behavior > > and specify how things work via a record. > > > > You can take a look at what I am thinking in this gist: > > > > https://gist.github.com/zkessin/8686881 > > > > I look forward to your comments. > > Kind of random thoughts in no particular order: > > I don't care about running on all kinds of databases. Postgres is a > must, SQLite would be nice to have, maybe Mysql. > > I do stuff like this all the time in Rails: > > Student.where("students.age > 30").include(:exams).map { |s| > [s.name, s.exams.map(&:grade)] } > > So support for more complex queries, joins, things like that would be > wonderful. > > Here's another kind of query I'd like to run without resorting to SQL: > > select students.id, students.name, count(exams.id) as examnum from > students join exams on (exams.student_id = students.id) group by > students.id, students.name. > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > -- You received this message because you are subscribed to the Google Groups "ChicagoBoss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at http://groups.google.com/group/chicagoboss. To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/f93c3958-555b-4205-ba9e-eae29e2081c1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
