in reply to Re: A Perl DBMS?
in thread A Perl DBMS?

dbm-deep has both multi-user and transactions. What more do you want?
My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^3: A Perl DBMS?
by Moron (Curate) on Mar 07, 2007 at 18:40 UTC
    Well a lot more! But I'll certainly look into your suggestion and evaluate how much it covers.

    Update: and it appears on the face of it that the "more" not covered by DBM::Deep includes, but is not limited to the following, although it could be used as a basis for implementing these on top:-

    - Support for Perl stored procedures

    - Transaction logging

    - System administration tools such as for listing users, locks etc.

    - backup/recovery

    - server startup/shutdown

    - bulk copy

    - a security model

    - user ownership and privileges model

    - group ownership and priviliges

    - run levels

    - support for logical and/or physical partitioning

    - virtual memory configuration and/or other tuning capabilities

    - quotas

    -M

    Free your mind

[reply]
      Remember - the point of a DBM is that it is much simpler than a full-blown oracle/mysql type DBMS. The best example of one is Berkely DB (aka, BDB). Please remember that when asking for features.
      • I do not agree with the theory behind stored procedures, so I certainly will NOT implement them myself. However, I will gladly accept fully-tested patches for it.
      • Logging of any kind requires additional files. DBM::Deep is supposed to be a single-file system.
      • Systems tools for listing users/locks ... more specs, please?
      • Backup of a single-file DBM is "cp".
      • There is no server to startup or shutdown - that's the point of a DBM.
      • Bulk-copy ... what are you looking for here?
      • A security model can make sense. I'll gladly take a set of tests to write code against. (I'm willing to write the code here, unlike for stored procedures.)
      • What are you referring to with runlevels?
      • What kind of partitioning?
      • There is almost no use of RAM, so no use of virtual memory. This goes along with the fact that there is no server. The DBM file is the shared point.
      • Quotas make sense with a security model. However, how do you anticipate handling logging in?

      In retrospect, it sounds like many of these features belong in Presto, not DBM::Deep. Does that ring closer to true for you?

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      A reply falls below the community's threshold of quality. You may see it by logging in.

In Section Meditations