in reply to A Perl DBMS?

Well perhaps there should be more "on the plus side" I was just kicking off a topic for discussion. For example, a storable doesn't automatically provide multi-user capability. I was thinking of something that would have the facilities of a Storable plus the scalability and transaction-handling of a DBMS with sufficient flexibility to be used in place of RDBMS's and offering everything that Perl can do already. I was thinking for example that you would be able to send it a Perl expression and it would preload data declarations for the database not just those in the script being sent across. And yes, I am sure there are plenty of people out there having a go or having already implemented at least some of such a spec. - but AFAK not yet definitelvely or completely.

-M

Free your mind

Replies are listed 'Best First'.
Re^2: A Perl DBMS?
by dragonchild (Archbishop) on Mar 07, 2007 at 18:37 UTC
    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?
[reply]
      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