Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • A few thoughts (Score:4, Interesting)

    by darobin (1316) on 2002.05.31 6:43 (#9001) Homepage Journal

    I don't know if you've looked in the direction of SleepyCat's latest baby, BerkeleyDB XML, but they might have solved or at least thought about some of the problems you list.

    2. Indexes.

    I guess this depends on the complexity of the indexing you intend to have. The simplest form is probably a token2ID mapping, where token could be anything (eg class name) and ID is whatever internal id you give the stored objects. It might in fact be sufficient for most cases, and means that it ought to be really simple to express indexing rules in Perl (whether they are constant or post-built).

    3. Querying. I'm not a big fan of trying to bend a sql like query language to fit an OO world;

    (Re)inventing a language is probably a bad idea indeed. One thing that could help you get away without a query language would be a simple way to express cross-product operations such as I want all objects that are in index Foo and in index Bar. Just a thought though.

    4. Uniqueness.

    Do the oids need to be human-friendly? If yes, you're in trouble, if not then it's probably a lot simpler. I would personally try to avoid being human-friendly at that level, and perhaps provide for naming with aliases (that aren't guaranteed to be unique by anything else than the user's intelligence) to real oids.

    --

    -- Robin Berjon [berjon.com]


    • (Re)inventing a language is probably a bad idea indeed. One thing that could help you get away without a query language would be a simple way to express cross-product operations such as I want all objects that are in index Foo and in index Bar. Just a thought though.


      The only tricky bit about this is deciding which is the least expensive index to compare against. Actually this is one of the ways we're thinking about doing it. There are actually a few mechanisms that we could use, but its choosing the b
  • Human friendliness. (Score:3, Informative)

    by pdcawley (485) on 2002.05.31 8:27 (#9010) Homepage Journal
    We've defaulted to using Data::UUID for our oid generation, though for a particular application I'm thinking of I plan on having 'pointer' objects which have 'computed' oids.

    So, say you are holding persistent state over a 'conversation' via email. Your session object has an opaque oid, but there's a bunch of pointer objects, the oids of which are the Message-IDs of all the messages in the conversation so far. Then, when a message arrives you use the last entry in the References: header as an oid to fetch a pointer, which leads you to your session data.

    Easy, and no need for any complex querying, just some careful thought about how you design your objects.

    Actually, this isn't the sort of 'uniqueness' I'm worried about. Say you go to the 'magic data pixie' (I'll get you for this Brocard) to get an object called (for the sake of argument) 'fred'. What should happen is that the pixie will go "Ooh look, there's an object called fred already in memory!" and return the aleady existing 'fred'.

    And (again ideally) it should be able to do this for objects called fred that haven't actually been stored in the database yet.

    The first part is relatively easy. The pixie just keeps a (weak) hash of all the objects it's fetched from the store and checks that first. The second part requires cooperation from various classes. If I really want it I'm going to have to make a Pixie::Cache object or something and provide an API for adding stuff to the cache.

    Hmm.
    • What you describe sounds a lot like what the enterprise people call "naming". I think there are CPAN modules revolving around that, have you look into them? I wouldn't be surprised if they took a simpler approach than what you need though.

      --

      -- Robin Berjon [berjon.com]