Using the term combustion was shortcut to avoiding discussing the details of highly oxygenated plasmas. BTW, oxygen plasmas are yellow, much like flames...

You mean like Chlorine trifluoride? Lol...

Funny, just a few years ago I was the chief software architect for a company purchased for more than 60 million dollars entirely for our enterprise product. One of the primary reason this company was acquired instead of its competitors was because we were pioneering open standards in our market verticals and supporting those open standards with public integration points that 3rd party companies, including our competitors, wrote integrations to.

This system had a persistence model that had to scale, not just horizontally, but in 'swim lane' fashion - or if you prefer the actual fashion we used, in AKF cube fashion. It handled tens of millions of persisted logic events daily and integrated with many different back end databases - all supported through this EXACT same facade/proxy system implemented with adapters. This pattern was used for all of the integration points and was how 3rd parties wrote integrations with our system.

So, whatever it is you do, you can rest assured that I write enterprise software in the "real world" and quite successfully.

You really just can't seem to understand abstraction.

Not at all. Again you demonstrate that you don't understand what abstraction is. By hiding the details of the persistence model, which means (so that you understand) that people using the abstraction interface don't know if it is a DB, or a file, or a web service, or a pipe, or a local process, or a remote process, the business logic simple deals with business objects.

If I was talking about abstracting the "business level" (presumably you mean business logic) I would be talking about an interface exposed to a view or consumer that didn't need to know any details about how the business logic operated. I was clearly not talking about that at all.

I'm willing to bet that you end up in a lot of 'arguments' where you bring out this line. It's okay, maybe some day you'll get it.

Well, in the real world, when you abstract things properly you don't expose a "connect" method. The code behind your interface - the adapter - would use connect and disconnect internally.

In the real world, when you abstract things, you expose a method that validates that the persistence layer is functioning/configured/usable as a normal part of the application/service/component's life-cycle. I called it ValidateConnection in this scenario because of the way he described his issue.

No, you don't, there are plenty of things that burn without oxygen simply because there are lots of other oxidizers. Oxygen just happens to be the most common.

In any case, the combustion being referred to isn't "burning" it is the light emitted by the compressed gasses, and with oxygen being much more exciteable than nitrogen and their being the two most prevalent gases in this scenario, that's what I was referring to. This is what you see from a 'flame' in any case.

"...so that you simply write an adapter for pushing/pulling data" makes you think the abstraction layer would have the DB layout in?

Let me be perfectly clear then, the abstraction layer would simply know about the business logic side of things and that you can store and retrieve those things in some fashion most likely represented by some criteria associated with them.

I don't know what you mean.

What? Who/what would already "have a connection" to another server or memory mapped file or process or socket?

ValidateConnection, in this example, would simply ensure that the backend persistence mechanism both exists and (as is required in most cases) that you have valid credentials.

Why would you be modeling anything relating to entities at the interface level?

iMyDatabase would have methods such as:

ValidateConnection
GetSomething
StoreSomething

It shouldn't know anything about how that data is stored, where it is stored, how your object is serialized/deserialized from a DB entity, et cetera...

The nitrogen under pressure remains inert, but the oxygen will combust at those levels. There's a great video of the plastic block they were testing with years ago with a huge wall of flame behind it as it traveled at mach 5 iirc...

I would have to agree about PostgreSQL, it is surprisingly flexible and powerful. I've used it for small business systems and recently on a 'big data' (oh, that overused buzzword...) project (millions of devices reporting dozens of times per day) and it has been fantastic.

Wish I'd gotten on the bandwagon 10 years ago.

...so that you simply write an adapter for pushing/pulling data.

Then you don't have to worry so much about making what appears to be an extremely premature optimization.

In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it.

Later, when you find out that you actually do need MongoDB, PostgreSQL, sharded MariaDB, whatever, you can simply write another adapter class that simply has to satisfy the iMyDBAdapter interface.

The reason this works so well is that it will force you to separate your business logic from your underlying DB implementation (which requires a lot of discipline to do otherwise, especially when you just want to get something 'done'.)

Also, as another poster pointed out, you're much more likely to suffer from other issues relating to scaling (and issues better solved elsewhere) than a modern database.

My advice, stick rigidly to the interface/adapter mechanism and implement an adapter for whichever DB you're most comfortable with right now.

The irony is that Apple chose this action clearly because it was intuitive to its users which is highly suggestive that Apple themselves think it mimics common behavior (deadbolts, slide to unlock briefcases, chain locks, et cetera.)

They want to argue that it isn't obvious, but that people will find it obvious... ;)

Gestures don't have physical representations on the screen (although they occasionally have 'trails'.) The 'slide to unlock' does. You literally slide what appears to be a latch, incredibly similar to "slide to unlock" briefcases (which have been around for more than half a century.)

Thank you for pointing out the AC's idiocy... People think that interference YOU CAN HEAR wouldn't be captured... LOL.