I actually renamed it to 'butterdb' a while ago because some people found fuckitdb hard to swallow. You can check out the code here: https://github.com/Widdershin/butterdb. I have grown a bit as a programmer since then, but I appreciate any feedback you might have.
I actually used this in production against my own recommendation to run the matching for /r/longboarding's Secret Santa. All of our data came from Google Forms, so it just made sense.
Thanks for writing this. Do you have plans to extend this to any locally stored spreadsheets? Ex: Excel, Calc (Libre and Open Office) and so on. I imagine even XML based documents would still present some vendor quirks to overcome.
I have considered it, and just opened an issue to track demand (https://github.com/Widdershin/butterdb/issues/14). I would probably use another library to handle parsing (and hopefully avoid some of those pitfalls), just like I rely on gspread to handle all Google Spreadsheets integration.
If you'd use butterdb if it had that feature, please let me know.
I explored this a bit (based off of the javascript-based http://sheetjs.com/sexql/) but the biggest difficulty is that people use CSVs and excel files in completely different ways for the same general task. In particular, different people set up budget workbooks in very different ways. There are also input problems and invalid files to deal with, so even if you manage to craft a meaningful integration you'd still have to figure out how to determine the structure and fix subtle non-uniformities
Thank you. I would use it right now actually as I do have some spreadsheets with Google. There are some I'd rather use locally like this and it would be just a nice extra. It would also avoid the need to maintain a network connection.
lol, when I was younger I learned that you can't use names like "fuckitdb" in front of customers / business stakeholders. Some better known software packages have also changed their names: FCKeditor, Testacular
ORM Stands for Object Relational Mapper. ORMS are software packages that map objects (class instances) to relational database tables (among other relational structures) and vice versa.
So maybe I'm nitpicking here but this project is not an ORM. There is no relational database here. Also it doesn't do joins, doesn't instrument attributes, makes no effort to convert object hierarchies to flat tables, etc, etc.
This is a (de)serialization library for google spreadsheets. Not much different from a CSV, XLS or even html table (de)serializer.
It's a nice hack though and certainly got its uses.
While technically true, you can somewhat simulate relational data. It would be interesting to see if any object-relational impedance mismatches are addressed.
Keep in mind languages evolve over time and definitions change ;)
It would have been more inappropriate. Which could be the goal, I don't know.
But more seriously, it's legally risky to have anything to do with code licensed under WTFPL because it does not actually specify that you can do anything with the code without possible legal reprisals, from which no protection is offered. Probably safe to point and laugh at it, though.
Although the WTFPL website (http://www.wtfpl.net/faq/) does note somewhat ominously that it hasn't been tested in courts, it seems legitimate enough to me. Is there any evidence outside of its lack of history in court that would indicate it isn't suitable for production use?
EDIT: gnu.org also says "We do not recommend this license" ,pointing to the Apache license as providing better protection against 'patent treachery'. (https://www.gnu.org/licenses/license-list.html)
The problem with WTFPL is that it's not clear that it lets you do the things that copyright usually prevents you from doing. In particular:
* It's not explicit that the user can redistribute the software freely.
* It's not explicit that you're free from warranty, meaning that, unlike basically all code ever written, you're on the hook for bugs and defects, just like a physical product.
Yes, it does say "do what you want," but that's not necessarily good enough for lawyers.
Track down what 'DannyBee has to say about WTFPL and licenses like it. There are good reasons not to use it even if you don't care what happens with your code.
I think the main thing is that even if you literally don't care what the fuck happens with your code you should at least make a statement that absolves you of responsibility, such as "THIS SOFTWARE COMES WITH NO WARRANTY" etc.
The capitals are generally a response to the "conspicuous" requirement of the UCC:
(2)Subject to subsection (3), to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be by a writing and conspicuous. Language to exclude all implied warranties of fitness is sufficient if it states, for example, that "There are no warranties which extend beyond the description on the face hereof."
I don't know if the definition of "conspicuous" has ever been tested in court, but that's the idea. I'd be interested to see it used as ammunition against clickwrap EULAs, though.
Digging on PyPI, I found the new package named butterdb. The version is bumped from .13 to .14, though that might just be the name change. In any case, it might be a good idea to change the submission to reflect the new name and the new package.
Based on the "don't use this for anything important" note, I think that's probably intentional. If someone spends the time to build this into something production-ready, they can change the name, too.
I actually changed the name from fuckitdb to butterdb in response to valid criticisms that alleged the name excluded people.
I originally intended this library to be a joke library, hence the "don't use this for anything important". I think I will remove that bit and just improve any issues people run into.
I actually renamed it to 'butterdb' a while ago because some people found fuckitdb hard to swallow. You can check out the code here: https://github.com/Widdershin/butterdb. I have grown a bit as a programmer since then, but I appreciate any feedback you might have.
I actually used this in production against my own recommendation to run the matching for /r/longboarding's Secret Santa. All of our data came from Google Forms, so it just made sense.
Hit me up if you have any questions.