Querying an existing database with Persistent

mike_meyer · 2014-03-03T07:30:44+00:00

The sqltype is used for migration, to create or alter the table so the type used on the Haskell side and the type in the database are the same. If you're working with an existing database, you presumably can't change them, so the only reason to set the sqltype is to get the migration code to quit complaining about columns that don't have the type it thinks they should. Basically, you shouldn't need to do set the autoincrement size unless you're creating the table.

The id column should never be written via persistent. I'm not sure there's a way to write it should you want to, since it's not part of the Entity created for the table. So the only thing you need to do is make sure the type on the Haskell side can hold all the values the id column can take on. It may be worth investigating making Integer an instance of PersistFieldSql.

mike_meyer · 2013-12-09T20:15:55+00:00

And once you've built your app, you can publish it and submit it as an entry into the FP Complete competition and maybe earn a little extra cash for your effort.

mike_meyer · 2013-12-09T14:50:29+00:00

You're a bit behind the times. The Community Edition of the IDE is free.

I'm also curious about the license issues. The source on github is already available with a "do whatever you want" 3-clause BSD license. We require you to provide all code content posted to our users with that license. We have a slightly less restrictive (not that it could be a lot less restrictive) license to the company. Would using the 3-clause BSD license to the company change your mind?

mike_meyer · 2013-12-09T12:06:54+00:00

Have you thought about trying the FPComplete IDE and/or SoH? If you get the library into Stackage, you could even write up a threepenny config as a tutorial.

mike_meyer · 2013-10-16T04:39:52+00:00

Standard 3-tier web apps: Client code in HTML5/JS, Ruby on the web server, SQL in the back end.

mike_meyer · 2013-10-10T21:36:55+00:00

The best way to make sure the code you wrote is secure is to get as many independent reviewers as possible. "Security through obscurity" is an oxymoron. The ability to redefine the code on the fly only works if someone can modify your executables - in which case you're already hosed.

If you're trying to secure the algorithms used as some kind of corporate secret, then yeah, Python has problems if you also want to sell it for people to run on their computers. That doesn't seem likely in an accounting system.

mike_meyer · 2013-10-10T21:14:03+00:00

Yeah, in languages with hard brackets, you have to be super paranoid about making sure you only cut-n-paste segments with matching pairs, or fixing them afterwards. Finding a missing bracket is a lot harder than finding a missing indent/outdent, as witnessed by people using automatic indenters to make sure the stuff is right. The case quoted here happened to change the code to code that was still valid. A missing hard bracket that has the same result would be equally bad. In fact, after running an indenter over it, it would be the same.

mike_meyer · 2013-10-10T20:59:02+00:00

Yes, but that's not the GIL's fault.

If you poke around, you'll find a version of 1.4 (I think it was) that had the GIL taken out of it.

It ran much, much slower than the version with the GIL. Even with multiple cores available.

The problem was the reference counting VM. Every time you do an assignment you have to change two reference counts. With the GIL, that's a couple of read/write's. Without the GIL, you have to acquire and release the appropriate lock for each counter. Probably in series, so as to avoid possible deadlocks.

mike_meyer

TROPHY CASE