While we are discussing any future plans, the current code base has a lot of work it could use to make it better. I'd still like to get it to a state where it more likely to be used by others. Plenty of variables need to be refined so they don't constantly throw errors and warnings. I have an updated todo list and I can give anyone access to if it you are interested.

Working towards any future version will take some time, so while we talk about it, we should focus on what we got too.

Posted by StapleButter

---

The issue of SQLAlchemy and ORMs in general is that they apparently tend to make simple queries really simple... and more complex stuff a nightmare.

IMO sending raw SQL would work best. Maybe with something like ABXD's querybuilder, so we're sure there is no SQL injection anywhere.

---

We don't have to use SQLAlchemy. In fact I belive Ninji found it very restrictive. It does have some very powerful features we could incorporate on our own. Mostly DB agnostic functionality, and the ability to self generate schema. We don't have to support every db variant either, I would say MySQL is a must, and an attempt at PostresSQL due to the way self deployed python works.

If we prepare the queries it will go a long way.

I've open this up to everyone so it is open to anyone who may be interested. Keep in mind while most of the chatter is about a possible recoding in the future our main focus is with 2.x. If you have ideas, experiences, or anything you would like to share about either 2.5+, future python/other languages coding suggestions, or wanting to help let us know.

Well best of luck to you! This code is an ambitious effort that's for sure. I do have a few suggestions:

Before you even get serious about coding, master a SCM (or Source Code Managment) system. We use 'git', but you could use any of the others really (hg, svn, etc). This would allow you to 'commit' changes and allow you keep track of when and who. This also allows you to wind back parts/the whole code to a place where and error was introduced and you fixed it. I would push for git for the simple fact it allows for a cool trick. Even if you fork our code you can do what is called a 'pull request' to have us bring parts of your code back into the main tree easily. It's complex, but a time saver

Posted by SquidGirl

---

Acmlmboard 2.7 is a future version that I thought up of to work on while 2.6 is being rewritten in the meantime. Currently, 2.7 doesn't exist yet but my test board can be considered a precursor to 2.7.

---

That version schema may further confusing things if you ever release the code publicly. The issue is since we had to do it once with board2. While it doesn't matter if you did call your base 2.7, it will sure cause confusion.. (and if we released a 2.7 more so).
While it's never been documented we do have a suggested versioning schema for forked versions.

The current one used for 2.5+ is: Acmlmboard 2.x.y Something (MM/DD/YYYY)
x = minor version. This only changes when we have a really large single code change, a stable code changes consisting of many 'maintenance releases', or a major milestone
y = maintenance release number. I usually change this number after a small changes, or a new feature is added.
"Something" = is optional. I use to denote "development", "experimental", or the name of a long term branch. Stable code does not have anything here.
Date = This the one part that changes the most. It's just the last date modified. It isn't always updated, but it's the quick way to tell if a very small change has been made.

(I wanted to document this since it hasn't been)

There have been variations in the past. Usually they use the + method

The first would look like Acmlmboard 2.5.2 +Squiddy-2.7.0 (MM/DD/YYY)

There are other things you can do of course. Add more numbers after 2.x.y, or even redo the whole line. Just a suggestion from the past.

It would be funny if we all coded AB in 5 or 6 different languages. I think that would be neat!

The tough part is you need to manage how to 'weave' the threads back together. Splitting should be easier. "post id >= id of spot to split: make new thread; change moved post's tid to new thread's tid;update existing thread's last data (user, date/time, etc);create last data for the new thread."

well that's not exactly how to do it, but that's a rough estimate. Merging is adding all the posts by updating tid than meta data, than moving the dead thread to a trash forum.

Again that's not a exactly how the backend would work, but that's a rough example.