It's kind of funny that no-sql databases are called that. Many of them actually do provide a query language, so it's not no-query-language, it's just different-query-language. And it's the relational aspects they differ most in, not the query language. Weird.

apropos nosql databases. when germans first hear "MongoDB" they think the name is a joke

Same here Benjamin.

Mongo is about the same as retarded in Norwegian.

RetardedDB..

When I heard they didn't provide referential integrity however, I felt like they really nailed the name.

they didn't provide a journal, when I first stumbled upon it. but at least they were already web-scale, back then

Did you hear about the recent thing where tens of thousands of MongoDB instances were broken into and the data was encrypted and they asked for a ransom to decrypt the data? I don't know what's worse, using default credentials for a public facing database or not backing it up so you actually would need to pay ransom 🙂

there problem with the default credentials is old, but the ransom is a new thing (I read about that on hackernews or heise.de)

it's maybe the same for a lot of XAMPP instances. I don't know if they change the default credentials for MySQL.

the simplest solution for MongoDB would be to allow without credentials when running on localhost, and only allow remote connections with credentials

MySQL is a dangerous thing to have public. We're actually converting all our public MySQL servers to a server-per-database artitechture. It requires a lot of memory, but memory is cheap these days and it solves a lot of problems, both related to performance and security.

We did the same with Apache on our webservers. Now we run 2000 instances of Apache on a single server, with Nginx in front.

2000 instances. that sounds huge. 🙂

Those servers have 256GB of RAM though 🙂

@hastebrot It sounds ludicrous but it works extremely well. We use cgroups quite heavily to enforce resource usage.

so

find()

uses a

DefaultScope

and

Scope

has

deregister()

. Do we need to deregister the scopes?

@hastebrot No, not needed for tests.

maybe it could be interesting, to print out the object graph of `Scope`s (and `Window`s)

I think the FEST Swing test framework prints out the "scene graph" for the node that caused an assertion error.

maybe we don't need this for `Scope`s, since we don't need to clean up `Scope`s for `View`s. we only need to create a new

View

in

@Before

but I don't know. global state is always something that causes problems, especially in tests

@edvin

FX.kt

is the only source file that contains global state variables (

DefaultScope

,

FX::companion

)?

there is also

PropertyHolder.selectionScope

in

CSS.kt

. but I think there is no need to watch out for it. also

DefaultErrorHandler.filter

maybe needs to be reset.

Rest.ongoingRequests

,

Workspace.activeWorkspaces

.

@hastebrot That sounds about right, everything state related is in FX. So you'd just wipe everything between tests, right?

Are there are dark themes? You know how popular electron apps are that are dark themed, like Atom, visual studio code, insomnia, ...

@sreich We've talked about creating some pre-built themes to distribute with TornadoFX. Eventually we most likely will, but we haven't gotten around to it yet.

But since it's all CSS, it's not that hard. Something as simple as:

class MainStyle : Stylesheet() {
    companion object {
        val base by cssproperty<Color>("-fx-base")
    }
    init {
        root {
            base.value = Color.BLACK
        }
    }
}

will get you most of the way there.

(or if you don't want to worry about stylesheets, adding

style { unsafe("-fx-base", raw("black")) }

to the root of your view will do the same thing)

@sreich Also, TornadoFX has a built in REST client, so your app shouldn't be too hard to build.