<razzy>
beneroth: did you compared pilDB and some other mainstream graphDB?
rob_w has joined #picolisp
<beneroth>
razzy, I compared it with mainstream relational databases and their ORM frameworks (which fake OOP-DB to application badly), and worked on projects in parallel using either tech.
<beneroth>
I don't have much practical experience with "other" graphDB, then again I understand no graphDB is really mainstream, closest is probably DB frameworks on top of postgres I guess.
<beneroth>
pilDB is not a true graphDB I guess, pilDB is a blend of relational (indexes, ACID CP-transactions), OOP-DB (OOP objects can be stored as records natively without any additional mapping/processing) and graphDB (records can directly be linked, no indirect lookup via foreign key required as it is the case with relational)
<beneroth>
when ignoring schema on db fields (practically using put function instead of 'put> method) or customizing/disabling its schema validation, then you get a document database, where you can have a custom schema in each record
<beneroth>
when you ignore the pilDB schema mechanics altogether you can use it as a pure key/value-store to work with persistent symbols
<beneroth>
so it is quite fluid, adaptable
<beneroth>
being reasonably efficient despite having no magic under the hood, everything can be inspected and tracked. which means other DBMS might be able to pull of some optimizations automatically, which in pilDB are up to the programmer (most importantly: don't do something inefficient, not so much about having to optimize anything, efficient tools are there for above-average-number of DB special topics e.g. including UB tree)
<beneroth>
then again in mainstream DB's often faulty optimizations/configurations make them slow or even losing data, such magic bad stuff cannot happen with pilDB
<razzy>
beneroth: thank you.
razzy has quit [Quit: leaving]
clacke has joined #picolisp
aw- has quit [Quit: Leaving.]
mmvmm has joined #picolisp
<mmvmm>
Is it possible to make pico lisp workable on 32 bit arm and how to make db migration in picolisp ?
rob_w has quit [Quit: Leaving]
alexshendi has joined #picolisp
<tankf33der>
mmvmm: you could compile legacy pil32 version on your arm
<tankf33der>
current pil21 is 64bit-only.
<mmvmm>
hmmm but 64 version should be fine for arm right?
<tankf33der>
No, your arm should be 64 too
<mmvmm>
I mean arm64. Is there any kind of JIT thing which will not work on arm (or something like that)?
<tankf33der>
you need just llvm eco system, should be fine. Contact me if you failed.
<tankf33der>
mmvmm: what is your arm linux distro?
<mmvmm>
rasbian
<tankf33der>
Should be fine.
<Regenaxer>
yes, arm64 is perfect
<Regenaxer>
I use it on Tertux/Android
<beneroth>
specific database files) might need an programmed migration to run in single user mode or even export/import. there are functions (@lib/too.l) to check database consistency and fix/rebuild indexes.
<beneroth>
mmvmm, db migrations: there is not a specific way to do it, but usually you do this with some picolisp/pilog code, and usually you can do it live without special considerations. normally it's just db changes as common in the application programming, even when they might be data changes to reflect a change in schema. schema changes might need a quick restart/reload of the application. very big schema changes (like changing allocation of records to
<beneroth>
so generally: needs some good understanding of the database and your use case, but then it's usually a short piece of simple code. change to break something into unusable state is low, and as the database is very transparent and can be well inspected it certainly is fixable.
<beneroth>
I've found pilDB less effort and easier to do changes than in comparable applications using other DBMS.
<beneroth>
I run productive pil databases for myself and commercial customers for 6 years.
razzy has joined #picolisp
alexshendi has quit [Quit: -a- Connection Timed Out]