New Model Setup

[Zachary Kessin]

Hi everyone

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.

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.

Note also that the existing code will not go away, just we will slowly migrate to the new structure

--Zach

[Daniel Widgren]

Hi Zachary,

We are working on a erlang ORM kind off system.

https://github.com/erldb/erldb

Right now it is in early early phase. :) But we will try to get some adapters up and so. But the idea is to have a better model then how it works in boss_db.

A not working branch on a mongodb adapter https://github.com/erldb/erldb_mongodb

We are gladly to get some more input on this.

We will add some documentation on how you write models for erldb.

- Daniel

2014-01-29 Zachary Kessin <zke...@gmail.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 chicagoboss...@googlegroups.com.
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/52E8F414.9000708%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Zachary Kessin]

We should talk, feel free to ping me on IRC or skype

--Zach

To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAL793oSW_tEUZH12sqvSQ7pHxS2pYEsb32qga%3DHtbVnCMsQo4w%40mail.gmail.com.

[David Welton]

> 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/

[Igor Clark]

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

[jim rosenblum]

Two thoughts about this:

1) Since Erlang is moving towards maps and away from records, would it be insane to suggest waiting until that transition is in place and migrating CB to maps and away from records? 

2) I understand that the parse_transforms are "Magic" and problematic, but from a *user* perspective, what CB offers now in terms of models is simple and (to me) elegant and I enjoy *not* having to interact with behaviors and the additional boiler-plate that I suspect would result.

my .02

[tome...@gmail.com]

+1 for maps

+1 for behaviours

I like having types specified in my projects and it sometimes is tricky,

when lots of parse transfomrs are used.

Behaviours are more explicit than parse transforms, easier to test and reason about

and I don't think they require that much biolerplate.

[_nato_]

I would suggest that there is still a place for records --

``Records still have their use case as is right now. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I prefer to prioritize semantics over syntax.''

https://news.ycombinator.com/item?id=7162113

I agree with him. 

[simon]

redis support would be great!

[Kai Janson]

... and CouchDB ... 

Sent from my non-google-device

On Feb 25, 2014, at 7:48 AM, simon <simon...@gmail.com> wrote:

redis support would be great!

--
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 chicagoboss...@googlegroups.com.
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/345a0007-6846-409e-8ee1-f249f7bb6676%40googlegroups.com.

[Peter Yuen]

Couchbase and Couchdb would be really great!!!!!

[na...@jeket.com]

I am curious to find out the progress of these changes. Is this something that people are still working on? Where can i go to find out more and review what is currently done?

[Jesse Gumm]

This has not happened yet, though I do agree completely with Zach's
initiative. I'm tackling boss_db stuff right now, and wrapping my head
around it before I go in and start changing fundamentals - for now,
I'm just getting tests to work properly. Once the higher-level tests
are working properly, I can start looking into exposing the magic of
boss_db.

-Jesse

> --
> 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 chicagoboss...@googlegroups.com.
> 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/d7535152-4e09-469b-b160-317edb30c4b4%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[David Welton]

> This has not happened yet, though I do agree completely with Zach's
> initiative. I'm tackling boss_db stuff right now, and wrapping my head
> around it before I go in and start changing fundamentals - for now,
> I'm just getting tests to work properly. Once the higher-level tests
> are working properly, I can start looking into exposing the magic of
> boss_db.

One thing that I think we ought to consider going forward: if it's
possible to do something that's nice and concise like boss_db without
all the compiler magic.

It really makes all of us dependent on the very few who have dived in
and figured out how things work.

[Jesse Gumm]

Indeed, I agree completely. I was getting a little too "meta" I think
there, and mostly failing with the analogy.

By exposing the magic, I more or less meant how when you expose how a
trick is done, it ceases to be magic. I like Zach's original plan,
and will look to try employ a similar method (it's basically how
simple_bridge works as well).

It will *absolutely* simplify the implementation and understanding of boss_db.

-Jesse

> --
> 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 chicagoboss...@googlegroups.com.
> 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/CA%2Bb9R_shk%2Bua_wk-wzGc_49qQmq5HyxKLSa1yAqkbbmjNi963Q%40mail.gmail.com.