On 11/03/2016 01:45, toki wrote:
On 10/03/2016 01:27, Wols Lists wrote:
On top of that, an integrity layer that enforces datatypes. This isn't part of
standard multi-value,
What? Back when I played with Pick, one of the selling points was that
one couldn't put the wrong type of data into a r
On 10/03/2016 11:37, Wols Lists wrote:
> And it would be nice to include an "easy to use" database with LO.
a) Doesn't LibO still include the db3 compatible database engine? If
so, that can be used;
b) I understand the dislike of SQLite, but for non-database programmers,
for most purposes, it i
On 10/03/2016 01:27, Wols Lists wrote:
> On top of that, an integrity layer that enforces datatypes. This isn't part
> of standard multi-value,
What? Back when I played with Pick, one of the selling points was that
one couldn't put the wrong type of data into a record field. Was that
feature si
> On 10 Mar 2016, at 10:37 PM, Wols Lists wrote:
>
> Well, all modern Picks implement SQL access.
>
> And as far as I'm aware, all modern RDBMS implement some form of stored
> procedure, ie have some form of internal programming language. I suspect
> end users will find the Pick way of dealing
On 10/03/16 08:51, Lionel Elie Mamane wrote:
>> > Pick, now generically known as MultiValue, is an n-dimensional
>> > database, and can be shown to be a proper superset of relational.
> Sorry to be blunt, but as long as it can be used as relational through
> SQL in a way that is close to the consen
On Thu, Mar 10, 2016 at 01:27:46AM +, Wols Lists wrote:
> On 09/03/16 18:06, Lionel Elie Mamane wrote:
>> On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
>>> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
On 08/03/16 13:32, Lionel Elie Mamane wrote:
>
On 09/03/16 18:06, Lionel Elie Mamane wrote:
> On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
>> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>>> On 08/03/16 13:32, Lionel Elie Mamane wrote:
>
At this point, I'd say, even more strongly than usual: the one t
On 09/03/16 17:59, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>> On 08/03/16 13:32, Lionel Elie Mamane wrote:
>
>>> At this point, I'd say, even more strongly than usual: the one that
>>> will do it will decide. Upgrading to a modern Java-based database
On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
> On 08/03/16 13:32, Lionel Elie Mamane wrote:
>> At this point, I'd say, even more strongly than usual: the one that
>> will do it will decide. Upgrading to a modern Java-based database
>> would maybe not be that bad after all...
> Soun
On Wed, Mar 09, 2016 at 06:59:08PM +0100, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 08:44:03PM +, Wols Lists wrote:
>> On 08/03/16 13:32, Lionel Elie Mamane wrote:
>>> At this point, I'd say, even more strongly than usual: the one that
>>> will do it will decide. Upgrading to a moder
On 08/03/16 13:32, Lionel Elie Mamane wrote:
> At this point, I'd say, even more strongly than usual: the one that
> will do it will decide. Upgrading to a modern Java-based database
> would maybe not be that bad after all...
Sounds like I'd better get my finger out then!
IF I can get the basics
On 8/03/2016 17:33, Norbert Thiebaud wrote:
On Tue, Mar 8, 2016 at 5:47 AM, SOS wrote:
A disruptive solution could be to abandon the "embedded" idea and replace
the current embedded engine by a new engine who use a spreadsheet file as a
"editable" storage who is protected for accidental edit
On Tue, Mar 8, 2016 at 5:47 AM, SOS wrote:
> A disruptive solution could be to abandon the "embedded" idea and replace
> the current embedded engine by a new engine who use a spreadsheet file as a
> "editable" storage who is protected for accidental editing.
Yeah sure, let's encourage people to
On 8/03/2016 15:47, Dan Lewis wrote:
On 03/08/2016 06:47 AM, SOS wrote:
A disruptive solution could be to abandon the "embedded" idea and
replace the current embedded engine by a new engine who use a
spreadsheet file as a "editable" storage who is protected for
accidental editing.
Currently
On 03/08/2016 06:47 AM, SOS wrote:
A disruptive solution could be to abandon the "embedded" idea and
replace the current embedded engine by a new engine who use a
spreadsheet file as a "editable" storage who is protected for
accidental editing.
Currently the use off a spreadsheet as database
On Mon, Mar 07, 2016 at 02:32:05PM +0200, Noel Grandin wrote:
> On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
>> A few examples of how SQLite differs from the SQL standard (be it de facto
>> or de jure standard) in quite deep, fundamental ways:
>> * lack of other datatypes than "integer", "re
A disruptive solution could be to abandon the "embedded" idea and
replace the current embedded engine by a new engine who use a
spreadsheet file as a "editable" storage who is protected for
accidental editing.
Currently the use off a spreadsheet as database works fine en is fast
enough for mo
On Mon, 2016-03-07 at 16:11 +0100, Lionel Elie Mamane wrote:
> On Tue, Mar 08, 2016 at 02:06:07AM +1100, Chris Sherlock wrote:
> > Is HSQLDB out of the question?
>
> HSQLDB2 and H2 are good choices if we decide to stay with a Java-
> based
> one (which brings performance problems because of the sl
On Tue, Mar 08, 2016 at 09:59:18AM +1100, Chris Sherlock wrote:
> Oh, and I’m not sure if this brings much to the table, but I wonder
> if we can simulate joins. After all, to get a right join you just
> swap tables, and you can actually simulate a full outer join with
> just a combination of othe
I understand, but the situation with Firebird seems less than ideal, at least
in terms of Windows builds at any rate.
Are the tests really that much slower? Obviously we are relying on having a
Java installation to test out Base.
Can we isolate those things that we can test on sqlite to sqlit
On Tue, Mar 08, 2016 at 02:06:07AM +1100, Chris Sherlock wrote:
> Is HSQLDB out of the question?
HSQLDB2 and H2 are good choices if we decide to stay with a Java-based
one (which brings performance problems because of the slowness of
crossing the C++-to-Java barrier).
> > On 7 Mar 2016, at 11:32
Is HSQLDB out of the question?
Chris
Sent from my iPhone
> On 7 Mar 2016, at 11:32 PM, Noel Grandin wrote:
>
>
>
>> On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
>> On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
>> A few examples of how SQLite differs from the SQL standard
On 2016/03/07 2:11 PM, Lionel Elie Mamane wrote:
On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
A few examples of how SQLite differs from the SQL standard (be it de facto
or de jure standard) in quite deep, fundamental ways:
* lack of other datatypes than "integer", "real" (fl
On Mon, Mar 07, 2016 at 08:23:53AM +0200, Noel Grandin wrote:
> In the space of open-source SQL database engines, SQLite is far and
> away the most widely used and supported option.
> Maybe we should try using that instead?
A few examples of how SQLite differs from the SQL standard (be it de fac
24 matches
Mail list logo
