Fork me on GitHub

What do you folks think of elixir?


@benbot I think its a very solid tool. I absolutely love their approach to errors.


If clojure had elm style errors :0


Oh sorry I mixed them up. I was actually referring to elm, silly me (


But yeah… clojure needs better error messages.


doesn’t ultra help with that?


I guess it’s just a better stack trace


I use AvisoNovate/pretty, its better than nothing but the stack traces are still not that helpful. Debugging errors in macros is usually a pain. I feel like I’ve somehow gotten a bit used to it after doing clojure for a couple of years now, but in the beginning it was a very rough experience.


I think debugging macros will always be a pain… just because of what macros are


actually, I'd prefer elm type system over elm errors


type system would eliminate so many run time errors


I don’t care much for strict type systems. It feels really restrictive in development


I like strongly typed languages though (looking at you JS)


Heh, just look at perl 😛


(although I am a fan of perl for my daily scripting needs)


One-offs, write-once and use? It's stellar.


in databases, are the targets of foreign-key always expected to be unique?


OMG. It's the first time that I see someone that writes PERL. I thought they were created together with the universe


@qqq it depends on the DB. There's also constraints that you can put on FKs that say stuff like that.


but a lot of it depends on what you mean by "unique"


@tbaldridge I am curious, can you name a relational database that does support non unique FKs?


And I'm pretty sure I've done it in MS SQL Server...but that's about 5 years ago, and I've forgotten a lot in that time, lol


do you remember the usecase for that? I just cannot come up with a good reason for this myself 😄


Sure, when you have a one-to-many relationship between two tables, but want that relationship enforced via constraints and FKs.


@tbaldridge Sorry if I have been unclear, I meant a reason for using non unique FKs in a relational database. You said you have done that in MS SQL server before.


Yeah, it's been a long time. But IIRC it was a situation where table A had a non-unique column (let's say "product type"), and B also had that column, and we wanted the situation where the product type in B had to be a value value from A. And for performance or simplicity reasons we didn't want to normalize product-type by breaking it out into its own table.


Like I said, it's been years since I've used SQL in my day-job, and that complexity like this is why I use Datomic now, lol


I see. That just calls for bugs and non defined behaviour I guess 😄


Thank you


@sveri, how so? A non-unique FK simply says "this has to exist in this other could exist multiple times, but it must exist"


I think @sveri accidentally answered this question in the #jobs-discuss … ?


(just so you know that he’s not ignoring you!)


Indeed, thanks for the hint


just repeating: @tbaldridge I understood this question that the column, that the FK refers to, does not have to be unique. How would a join behave if product-table is refered via ID and the table can have id "100" twice?


Don't LEFT JOINS already do that? You get results from table A duplicated for each result in B.


The semantics are the same, IMO, it's just a way of saying "any value in this column must exist in this other table"


Ok, lets make the example more explicit. I have a user table that refers an address table via id. The id column in the address is not unique. So user foo refers to address 100 via id. In the address table there are two rows with id 100. 1. points to the northpole 2. points to the southpole. Which is the correct address?


No, that's not the way you would do it. Let's reframe the situation a bit:


You have users, and a address table. Each address contains a "region" column. The user table also includes a "region" column. Then you have a non-unique FK from user.region to address.region. All that relationship says is: "Before you can create a user with a region X that region must exist attached to an address".


Like I said, this isn't super common, but I have hit it at times when normalizing "region" would require a huge refactor or a big performance drop.


And in this case, it's more of a constraint. A way of locking down valid values for user.region.


Which would have to be enforced in application logic, correct?


No, if you tried to insert "Bleh" into users.region, you would get a FK constraint failure from SQL.


All a FK is, is a bit of info on a column saying "Any value in this column but be found here....". How "here" is defined is up to the DB, but there's no technical reason it has to be unique. Most of the time the only restriction is that "here" has to be indexed.


In this case it makes sense, I would still shy away from it if there are different ways where the penalty is not to much. Of course, refactoring a whole application and maybe several dozens tables could be of these cases.


The note that I saw w/ relation to the InnoDB implementation was that it causes cascading triggers to behave incorrectly, iirc. But as far as I know, those are in far less use these days.


@sveri @tbaldridge @fellshard : I'm implementing a minimal db of sorts. I now have supports for (1) unique field and (2) foreign keys. Is there a list of database constraints somewhere I can look at? The motivation behind all this is building towards


This is definitely a case of 'don't ask me' ¯\(ツ)


The only DBs I've had the (dis)pleasure of using have been SQL Server and DynamoDB 😐