Professional Web Applications Themes

Database applications and OOness - Ruby

People, I'm going to write an application that needs to deal with reasonably large amounts of data over a reasonably long period of time. So the question that immediately comes up is, how do I store said data when the program is not running? As I see it, the options can be divided into two categories in two different ways: How the data is stored and how it is interfaced. The data can be stored in (essentially) one of two ways: in memory, or on disk. In my case, in-memory systems are probably no good - with the volumes of ...

  1. #1

    Default Database applications and OOness

    People,
    I'm going to write an application that needs to deal with reasonably
    large amounts of data over a reasonably long period of time. So the
    question that immediately comes up is, how do I store said data when the
    program is not running? As I see it, the options can be divided into two
    categories in two different ways: How the data is stored and how it is
    interfaced.

    The data can be stored in (essentially) one of two ways: in memory, or
    on disk. In my case, in-memory systems are probably no good - with the
    volumes of data I want to hold, and the periods of time I want to hold
    them over (some if it is accounting data, which is likely to be kept for
    years) I don't want it all in memory. Therefore, I will choose a
    disk-based system such as an RDBMS. My RDBMS of choice is PostgreSQL, so
    I'll run with that for now.

    The other way my options can be divided is (and I'm simplifying things a
    bit again) between those libraries that present the data as objects and
    those that present it as database rows. Let me clarify:

    #<Person:0x40132728 name="name", number="phone number", address="address">
    vs
    ["name","address","phone number"]

    I like the first one better, because you get encapsulation and behaviour
    with your data, but most of the database interface libraries that I've
    seen of that type tend to take most of the querying out of the hands of
    the user. They allow you to retrieve objects that have properties that
    match a given example, but very seldom any more complex than that - the
    equivalent of limiting yourself to "SELECT * FROM table WHERE
    table.column = ?" type queries only. Part of the reason I like RDBMSs is
    that I can do complex queries which don't necessarily return a simple
    list of objects, like:

    "SELECT s.name AS name, COUNT(DISTINCT t.customer_id) AS customers
    FROM salesperson s JOIN transactions t ON s.id = t.salesperson
    ORDER BY customers DESC;"

    This really returns a salesperson-to-integer mapping of how many
    customers a salesperson has dealt with. You can't represent this as a
    plain list of objects, unless you created a special type of object just
    for it (which is silly) and most OO-type database libraries won't let
    you make that sort of query at all without going behind their backs,
    which is really ugly.

    The alternative is to use something like vanilla DBI, in which you write
    your own SQL and everything comes back as arrays of values. This allows
    you to do whatever queries you want but you lose the niceness of the OO
    approach. I don't want to do vanilla DBI, it's too messy.

    What I want is some sort of happy medium, and I'm starting to think I'll
    have to write it as none of the database interface libraries I've
    evaluated do it the way I want - which is the motivation for writing a
    lot of software, is it not? I believe that's how Ruby itself got its
    start, so I'm in noble company...

    But also on a deadline. Any suggestions?

    Tim Bates
    --
    id.au

    Tim Guest

  2. #2

    Default Re: Database applications and OOness


    "Tim Bates" <id.au> schrieb im Newsbeitrag
    news:id.au...
    [snip persistent storage selection] 
    address="address"> 

    There are however object relational mapping tools that come with their own
    query language. These query languages are most likely not as powerful and
    flexible as SQL but they ten to be more flexible than QBE (query by
    example), which you mention.
     

    You didn't say whether your project has Ruby as a requirement written on
    it or whether tools you use must be free. In case not, you could consider
    object relational binding tools like

    - Lafcadio (Ruby, free)
    http://rubyforge.org/projects/lafcadio/

    - Apache OJB (Java, free)
    http://db.apache.org/ojb/

    - JDO implementations (Java, not all free, comes with it's own query
    language)
    http://java.sun.com/products/jdo/
    http://jdocentral.com/

    etc.


    Or you consider an OO database and write only the query language pr
    yourself. You could then use

    - db4o (Java, commercial with reasonable pricing) with SODA query
    language
    http://www.db4o.com/
    http://www.odbms.org/soda/

    etc.

    You'll probably notice that I'm coming from a Java background. :-) I'm
    sure there are similar tools for other languages.

    Kind regards

    robert




    Robert Guest

  3. #3

    Default Re: Database applications and OOness

    il Wed, 7 Jan 2004 19:06:32 +0900, Tim Bates <id.au> ha
    scritto::

    have you ever looked at the Criteria library ?
    gabriele Guest

  4. #4

    Default Re: Database applications and OOness

    On Wed, Jan 07, 2004 at 08:16:40PM +0900, gabriele renzi wrote: 

    Yes, in fact I wrote a DBI module for it. It's great; if I were going to
    write an OO DBMS interface I'd use it, or at least some of the code and
    ideas from it. But it doesn't solve the whole problem - only the
    querying bit, and even then it can't quite manage queries as complex as
    the example I gave with in the OP. It still only returns (at best)
    arrays of data, and does nothing about turning them into first-class
    objects.

    I don't know if there is a solution to my problem, whether what I want
    can be done cleanly. To tell the truth I'm not 100% certain of what I
    want, but I visualise something like a cross between Vapor and Criteria.
    If no such thing exists, and I can't find an alternate solution I guess
    I'm back to writing it myself, or settling for some other method. It
    just seems like there should be a good way to marry the power of SQL
    (and the optimised searching/indexing and concurrency routines a good
    RDBMS provides) with the pristine Object-Orientedness of Ruby.

    Tim Bates
    --
    id.au

    Tim Guest

  5. #5

    Default Re: Database applications and OOness

    Tim Bates <id.au> wrote: 

    What would you like it to return? Should it construct a class on the fly,
    with fields 'name' and 'customers'? And should it use its own query
    language to do so, or p the sql query?

    martin
    Martin Guest

  6. #6

    Default Re: Database applications and OOness

    If your application can be written in Java, check Hibernate (
    www.hibernate.org ). The learning curve is not insignificant, but IMO, well
    worth it.

    Matt


    -----Original Message-----
    From: Tim Bates [mailto:id.au]
    Sent: Wednesday, January 07, 2004 5:07 AM
    To: org
    Subject: Database applications and OOness


    People,
    I'm going to write an application that needs to deal with reasonably
    large amounts of data over a reasonably long period of time. So the
    question that immediately comes up is, how do I store said data when the
    program is not running? As I see it, the options can be divided into two
    categories in two different ways: How the data is stored and how it is
    interfaced.

    The data can be stored in (essentially) one of two ways: in memory, or
    on disk. In my case, in-memory systems are probably no good - with the
    volumes of data I want to hold, and the periods of time I want to hold
    them over (some if it is accounting data, which is likely to be kept for
    years) I don't want it all in memory. Therefore, I will choose a
    disk-based system such as an RDBMS. My RDBMS of choice is PostgreSQL, so
    I'll run with that for now.

    The other way my options can be divided is (and I'm simplifying things a
    bit again) between those libraries that present the data as objects and
    those that present it as database rows. Let me clarify:

    #<Person:0x40132728 name="name", number="phone number",
    address="address">
    vs
    ["name","address","phone number"]

    I like the first one better, because you get encapsulation and behaviour
    with your data, but most of the database interface libraries that I've
    seen of that type tend to take most of the querying out of the hands of
    the user. They allow you to retrieve objects that have properties that
    match a given example, but very seldom any more complex than that - the
    equivalent of limiting yourself to "SELECT * FROM table WHERE
    table.column = ?" type queries only. Part of the reason I like RDBMSs is
    that I can do complex queries which don't necessarily return a simple
    list of objects, like:

    "SELECT s.name AS name, COUNT(DISTINCT t.customer_id) AS customers
    FROM salesperson s JOIN transactions t ON s.id = t.salesperson
    ORDER BY customers DESC;"

    This really returns a salesperson-to-integer mapping of how many
    customers a salesperson has dealt with. You can't represent this as a
    plain list of objects, unless you created a special type of object just
    for it (which is silly) and most OO-type database libraries won't let
    you make that sort of query at all without going behind their backs,
    which is really ugly.

    The alternative is to use something like vanilla DBI, in which you write
    your own SQL and everything comes back as arrays of values. This allows
    you to do whatever queries you want but you lose the niceness of the OO
    approach. I don't want to do vanilla DBI, it's too messy.

    What I want is some sort of happy medium, and I'm starting to think I'll
    have to write it as none of the database interface libraries I've
    evaluated do it the way I want - which is the motivation for writing a
    lot of software, is it not? I believe that's how Ruby itself got its
    start, so I'm in noble company...

    But also on a deadline. Any suggestions?

    Tim Bates
    --
    id.au

    Lipper, Guest

  7. #7

    Default Re: Database applications and OOness

    Tim Bates wrote: 

    Tim,

    I think I have an inkling of what you want.

    My take on it is this: If you're going to do some coding to
    meke this happen, it's easier to take an existing DB (with
    fancy query capabilities and presumably efficient, reliable
    data storage) and graft an OO layer onto it. (Easier, that is,
    than vice versa.)

    For example, you might wrap a query in a method that returned
    a Struct whose member names were the database field names.

    I'm sure there are complications there, but they shouldn't be
    of the same order of magnitude as a full database with a full
    SQL pr.


    Hal



    Hal Guest

  8. #8

    Default Re: Database applications and OOness


    On Thu, 8 Jan 2004, Hal Fulton wrote:
     

    I write a lot of code that provides some sort of web based view or
    application to data stored in a database, and I find myself following a
    repeated model where I define a Struct that represents a row of data.
    This is very convenient for my manipulation fo the data, but there are
    complications that arise.

    The first is that if I change the database schema, I also have to then go
    change the struct code to match, and the second is that I write a lot of
    the exact same sort of SQL to query data with the same Ruby around it to
    put that data into my struct, and when I change the database schema, I
    then need to go change all of the SQL that is affected.

    What I need is a layer that, given a db table, will generate a Struct that
    encapsulates that data and provides a few convenience methods for querying
    data from the table into one or more objects, and for pushing the data
    from the objects back to the db.

    So far as I have been able to determine, there's nothing on RAA that does
    this. Am I overlooking something, or is this something that I need to
    write myself?


    Thanks,

    Kirk Haines



    Kirk Guest

  9. #9

    Default Re: Database applications and OOness

    > I write a lot of code that provides some sort of web based view or 

    I have a system that was developed in house. It is not exactly what
    you are asking for. I call it SPOM (Simple Persistent Object
    Manager). The keyword is SIMPLE.

    It basically has 2 layers. SpomDB is a wrapper over a DBI
    connection. It can take an arbitrary sql query and will return an
    array of newly created Objects. The objects will have members that
    are the same names as the query names (unless they are invalid ruby
    names) but they can also be accessed via [], like an array would.
    This makes it convenient to do an arbitrary query. But it currently
    does support modifying and resaving this type of object (would not be
    hard to add, but I haven't needed that).

    Above this is SPOM, a manager of sorts. It takes a spomDB and you
    can add xml file mappings to it. The xml file mappings allow you to
    map between the db and any given object. You can add data type
    mappings (ie it is stored as a char in the db but in ruby it is a
    boolean). You can also have sub-objects mapped. So you can have a
    person object, that has an address object that has a zip code object.
    You can then access the ruby object via person.address.zip.code (ie
    it creates the sub objects and fills them for you). Please keep in
    mind this is a simple one object to one table mapping not
    relationships between tables (it is simple).

    It is used in house to read in and transfer data between SQL Server,
    Informix, Dataflex, and DBF databases. Its primary intent was to
    extract data from legacy systems. Using the mapping files, you can
    also do basic CRUD operations, but there currently is NO transaction
    support, no connection pooling, no object query interface (ie you use
    sql), no multi-table mappings or join support. I do plan to add
    these things, but it will take time, right not SPOM supports our
    basic in-house needs.

    If there is an interest in this I could release it next tuesday to
    RubyForge. (I would simply need to present this to our executive
    group meeting on tuesday, more of a formality, but that's our
    protocol for this) Also note that there is very little doention,
    I'll try to add some if there is interest.
     



    Walt
    ************************************************** ***
    Walter Szewelanczyk
    IS Director
    M.W. Sewall & CO. email : com
    259 Front St. Phone : (207) 442-7994 x 128
    Bath, ME 04530 Fax : (207) 443-6284
    ************************************************** ***



    walter@mwsewall.com Guest

  10. #10

    Default Re: Database applications and OOness

    As somebody who's done some of this work (I wrote Lafcadio), I
    strongly recommend that you consider extending somebody else's work
    before doing it yourself. When you enter this problem domain there are
    a lot of little wrinkles you run into, and the best solution isn't
    always necessarily obvious from the start. I know that personally it
    took me a while to figure out the best way to transparently handle
    relations between different rows, for example.

    Now, I've only used Lafcadio, but I have the feeling that right now
    the Ruby OR-mapping tools out there are either 1) strong on mapping
    rows to objects, or 2) strong on ad-hoc querying, but not both. I'd
    put Lafcadio and Vapor in category 1, and Criteria in category 2.
    Either requirement is pretty big; both are twice as big. In the
    long-term, my feeling is that any library that sticks around in this
    space will have to satisfy both needs.

    In the short-term, I can tell you what you'd have to do for Lafcadio
    to get it do what you want. First, Lafcadio was written first for
    MySQL, and although it should support Postgres with minimal changes, I
    have yet to implement or test such a change. (At RubyConf Ryan Davis
    told me he was very interested in helping add Postgres functionality,
    and I moved the library to DBI to enable that, but I suspect that,
    like everybody else, Ryan's pretty busy.) Second, Lafcadio's support
    for querying works, but I'll be the first to admit that it's verbose
    and ugly as hell. Query inference is very high on my list, but then,
    I'm busy, too. So Vapor or Criteria might be a better choice for you,
    depending.

    At the least you might want to poke around in the various libraries
    and steal the best ideas for yourself.

    Francis


    Tim Bates <id.au> wrote in message news:<id.au>... 
    Francis Guest

  11. #11

    Default Re: Database applications and OOness

    > -----Original Message----- 
    I liek the look of ROE
    (http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&ent
    ry=3246121322) on Squeak. Don't know if its what you're looking for of
    course, since even you don't know what you're looking for :)

    David
    http://homepages.ihug.com.au/~naseby/


    David Guest

  12. #12

    Default Re: Database applications and OOness

    il Wed, 7 Jan 2004 19:06:32 +0900, Tim Bates <id.au> ha
    scritto::

    on a sidenote: someone agrees with me that we should have a common
    shared and abstract ruby/DBMS api like python/java/whatever instead of
    a wrapper package (DBI)?


    (I hinted this long time ago and had no answer at all. Falling in
    Warnock's Dilemma, so I post again..)
    gabriele Guest

  13. #13

    Default Re: Database applications and OOness

    On Wed, 7 Jan 2004, gabriele renzi wrote:
     

    yaml?
     

    -a
    --

    ATTN: please update your address books with address below!

    ================================================== =============================
    | EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
    | PHONE :: 303.497.6469
    | ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
    | STP :: http://www.ngdc.noaa.gov/stp/
    | NGDC :: http://www.ngdc.noaa.gov/
    | NESDIS :: http://www.nesdis.noaa.gov/
    | NOAA :: http://www.noaa.gov/
    | US DOC :: http://www.commerce.gov/
    |
    | The difference between art and science is that science is what we
    | understand well enough to explain to a computer.
    | Art is everything else.
    | -- Donald Knuth, "Discover"
    |
    | /bin/sh -c 'for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done'
    ================================================== =============================

    Ara.T.Howard@noaa.gov Guest

  14. #14

    Default Re: Database applications and OOness

    On Wed, 7 Jan 2004 21:12:06 +0900
    Tim Bates <id.au> wrote:
     
    >
    > Yes, in fact I wrote a DBI module for it. It's great; if I were
    > going to write an OO DBMS interface I'd use it, or at least some of
    > the code and ideas from it. But it doesn't solve the whole problem -
    > only the querying bit, and even then it can't quite manage queries
    > as complex as the example I gave with in the OP. It still only
    > returns (at best) arrays of data, and does nothing about turning
    > them into first-class objects.[/ref]

    I just noticed a thread discussing Criteria in passing. ;-) Looking
    at the original post, I don't think the query is that hard to
    generate:

    require 'criteria/sql'
    include Criteria

    s = SQLTable.new("salesperson")
    t = SQLTable.new("transactions")

    q = s.*.left_outer_join(s.id == t.salesperson, s)
    q.order_by = :customers
    q.order = :desc

    q.select(s.name, "COUNT(DISTINCT #{t.customer_id})")

    # => SELECT salesperson.name, COUNT(DISTINCT
    # transactions.customer_id) FROM salesperson LEFT OUTER JOIN
    # salesperson ON (salesperson.id = transactions.salesperson) ORDER
    # BY customers desc

    Granted, it doesn't generater column headings, and you currently have
    to use a literal string hack to get the SQL function. This should
    hopefully be fixed before long.
     

    I'm not sure what Vapor is, but---and I know you've mentioned it so
    you're aware of it---you may take a look at Mephle, since I think it
    does what you want:

    class Foo
    # When you call these, they automatically update the proper
    # row in the table.
    attr_accessor_indexed String, :bar, :baz
    attr_accessor_indexed Integer, :quux

    :
    end

    Things are a little less automatic than I'd like at the moment.
    Writing this has given me an idea of how to fix it, though, with an
    'auto_index' function, so you'd have something like:

    class Foo
    IDX = DBITable.new(...)

    def initialize(...)
    :

    auto_index(IDX)
    end
    end

    This could look at the column titles (or a list of what
    attr_accessor_indexed declares) and insert a row with the proper
    data. (Right now you have to do a manual insertion, which isn't too
    tough either.)

    There are a few reason I still serialize and index instead of using
    tables exclusively:

    1. Some objects are large, and you don't want to index everything
    2. Looking up attributes every time is slow
    3. Not all ruby things can be represented as SQL things
    (4. SQL isn't guaranteed to be the storage mechanism, either)

    I'm open to suggestion though. It's conceivable that there's a
    "CachedTableObject" class or something where you give up the ability
    to write into a live system, and you avoid point 2, for objects that
    work. Of course, you still need to be able to load that object later,
    and using a unique OID for every object in the system is nice, so
    you'd still have something in the object table. I'm not sure what you
    gain by this one other than a few extra bytes, but it could be done.

    Making Mephle indexing less manual is probably a lot more useful---you
    get what you want without any work (and there's not really much as it
    is).

    --
    Ryan Pavlik <com>

    "Spinal hazards *are* hazardous..." - 8BT


    Ryan Guest

  15. #15

    Default Re: Database applications and OOness

    On Thu, Jan 08, 2004 at 04:56:40AM +0900, Francis Hwang wrote: 

    Absolutely, I wouldn't want to write yet another database interface if I
    could find one that suited me, with or without some modification. The
    interface is not the point of this project.
     

    This is my experience also, which is why I started this thread.
     

    Criteria doesn't do any of category 1 at all, so yes.
     

    Uhuh. But none of them have quite cracked it yet.
     

    Vapor, to give an example, is very targeted at Postgres and uses a lot of its
    more advanced features (in particular it integrates Postgres's
    transaction model quite closely into its behaviour). Criteria, to give
    another example, is running into problems because of subtly different
    query syntaxes between different databases (MySQL's "RLIKE" vs
    Postgres's "~", for example). Does Lafcadio suffer from either of these
    constraints? In particular I'd like to have a fair bit of control over
    when and where transactions are used - it's particularly critical in
    cases like

    "BEGIN;
    UPDATE accounts SET balance = balance - 100 WHERE accnum = 1743;
    UPDATE accounts SET balance = balance + 100 WHERE accnum = 329;
    COMMIT;"

    If I were to do a similar thing in Ruby code, I'd need to be sure that
    the account balance that I was using in the calculation was up-to-date
    (otherwise the effects of someone else's transaction might get wiped)
    and also that if the second UPDATE in the example above failed for some
    reason then the first one would get rolled back. Can Lafcadio do, or be
    made to do this?
     

    I am also interested in getting it to work with Postgres, if it solves
    my problem. I'm pretty busy too, but I have time set aside for this
    project that I can't really start on until I deal with this issue.
     

    I wouldn't consider Criteria to be in quite the same basket as Lafcadio
    and Vapor. It doesn't have any OO abstraction at all (on the data side -
    the project is all about OO abstraction of queries) I think Lafcadio (or
    Vapor) could take a lot of ideas (and/or code) from Criteria for their
    own query interfaces. I had independently thought of some of the
    concepts behind Criteria when I discovered that somebody had already
    written it, and in a much cleverer way than I would have thought of, but
    it's not primarily a database interface library, it's a query
    construction library. A project that combined the best aspects of the OO
    data interfaces and the OO query interfaces that we already have would
    be exactly what I was looking for.

    Perhaps I'll start looking into how to a) get Lafcadio to work with
    Postgres and b) get Lafcadio or Vapor to work with Criteria.

    Tim Bates
    --
    id.au

    Tim Guest

  16. #16

    Default Re: Database applications and OOness

    On Thu, Jan 08, 2004 at 05:55:23AM +0900, Ryan Pavlik wrote: 

    Well this doesn't actually work, because the ORDER BY clause references
    a column name ("customers") that doesn't exist, and also in
    Criteria-1.1a at least when I tried this it failed with
    NoMethodError: undefined method `join' for :customers:Symbol
    from /home/tim/ruby/ln/criteria/sql.rb:243:in `_mkorder'
    from /home/tim/ruby/ln/criteria/sql.rb:287:in `select'

    I realise that these are minor things. If I can help fix them, I will -
    tell me what needs to be done. I am keen to get this working.
     

    I did look at Mephle, but I seem to remember you telling me not that
    long ago that it *wasn't* what I wanted. :P
     

    I'm not sure I quite follow you here. The approach that Vapor (and I
    think Lafcadio) takes is to look up an attribute only when the object is
    loaded or explicitly refreshed, and just keep the value in memory, so if
    the same accessor method is called multiple times in succession only one
    database query is made. I think this is what you mean by "giving up the
    ability to write into a live system".

    Also, I'm not entirely clear on what you mean by indexing in this
    context. I am very likely to set up the database tables and SQL indexes
    manually, so those columns that will contain a lot of data will
    naturally not be indexed. I'm not sure if you're referring to SQL
    indexing though, I haven't looked that closely at Mephle.

    Points 3 and 4 are rather moot. Point 3 because in my case I will be careful to
    only put into the database that which can be represented in SQL. I don't
    really want a library that hides all the SQL from me, I know what I'm
    doing in that regard. Point 4 because my project will only ever store
    stuff in SQL, although I realise that this is not a reason for you to
    abandon that approach as I'm not the only one who may use your library.

    Tim Bates
    --
    id.au

    Tim Guest

  17. #17

    Default Re: Database applications and OOness

    I would like to see a Ruby library along the lines of Alphora's
    Dataphor product:

    http://www.alphora.com/tiern.asp?ID=DATAPHOR

    Regards,

    Mark Wilson


    Mark Guest

  18. #18

    Default Re: Database applications and OOness

    On Thu, 8 Jan 2004 09:11:16 +0900
    Tim Bates <id.au> wrote:
     [/ref]
    <snip> 

    Hmm. I really need to release 1.2. You can always grab the latest
    from svn:

    http://svn.mephle.org/svn/mephle/criteria

    IIRC, 1.1a had a number of things in need of fixing.
     

    Oh, yeah, you need "COUNT(...) AS customers". Hopefully this will be
    fixed by 1.2 as well.
     
    >
    > I did look at Mephle, but I seem to remember you telling me not that
    > long ago that it *wasn't* what I wanted. :P[/ref]

    Oh? ;) Hrm, I probably misunderstood what you were after.
     
    >
    > I'm not sure I quite follow you here. The approach that Vapor (and I
    > think Lafcadio) takes is to look up an attribute only when the
    > object is loaded or explicitly refreshed, and just keep the value in
    > memory, so if the same accessor method is called multiple times in
    > succession only one database query is made. I think this is what you
    > mean by "giving up the ability to write into a live system".[/ref]

    Right. You couldn't have someone else talking to the database at the
    same time, at least to write. If you can't do that, I don't see what
    advantage it provides to store objects this way (instead of just
    indexing them).
     

    Yes, this is pretty much what I do with Mephle. Objects are stored by
    serializing (via Marshal) and writing that to an Object table.
    Anything I need for quick lookup, I stick into a table using Criteria.
     

    Well, it hides the object storage bits, since they're the same for
    everything. Indexing and SQL stuff is abstracted via Criteria of
    course, but that's still "right there". Viability depends on how you
    want things to work, but you might check it out.


    --
    Ryan Pavlik <com>

    "Spinal hazards *are* hazardous..." - 8BT


    Ryan Guest

  19. #19

    Default Re: Database applications and OOness

    On Wed, Jan 07, 2004 at 10:16:42PM +0900, Martin DeMello wrote: 
    >
    > What would you like it to return? Should it construct a class on the fly,
    > with fields 'name' and 'customers'? And should it use its own query
    > language to do so, or p the sql query?[/ref]

    I don't know. Probably an array of arrays or an array of hashes - which,
    I know, is exactly what DBI would return for such a query. The point I'm
    trying to make is I'd like the system to be able to handle this sort of
    query _as_well_as_ the "SELECT * FROM table WHERE property = ?" type
    return-a-list-of-objects query. I don't know of any system that can do
    that, or even if it could be done neatly. Possibly such a system would
    have to accept two sorts of query and handle both separately, but that
    introduces its own ugliness.

    Tim Bates
    --
    id.au

    Tim Guest

  20. #20

    Default Re: Database applications and OOness

    On Thu, Jan 08, 2004 at 05:03:41AM +0900, David Naseby wrote: 

    This article has a point that I've seen before, namely that object
    models don't necessarily have a 1-to-1 mapping to relational models:
    "[Object-relational mapping] adds a huge amount of complexity to a
    project, and with dubious benefits: when you're not tracking down
    bugs in the mapping framework or obsessing about performance, you're
    chopping toes off your object model so you can shoehorn it into a
    relational schema."

    The OO relational-query model he describes looks very much like
    Criteria, and I think if I were to go along that route I would
    definitely use Criteria and DBI. But some inner Ruby demon is constantly
    telling me that I'd really like to represent my data as first-class
    objects _when_possible_, which Criteria doesn't even try to do.

    Essentially, now, I think I want Lafcadio on Postgres with Criteria (or
    Criteria-like) queries and transaction support. I like the way (and
    correct me if I'm wrong about this) Lafcadio uses the RDBMS the way it
    was meant to be used - unlike Vapor (which adds extra tables and columns
    for metadata and generally wrests control of the RDBMS out of the hands
    of the user) or Mephle (which basically only uses the RDBMS as somewhere
    to write data to). I don't like Lafcadio's query model (which I
    haven't tried to use, but the author himself assures me is "ugly as
    hell") and I do really like Criteria's query model, so the best of both
    worlds there would just about be enough to satisfy me.

    I'm pretty fixed on using an SQL back-end, because it outsources much of
    the calculation and concurrency issues to another program which is built
    for it, but just so I can say I have considered all the options can
    someone tell me if there's a non-SQL OO solution out there which, most
    importantly, doesn't store all its data in memory all the time - some of
    my data needs to be kept for a long time but will very seldom be
    referenced, and I don't want to have to manually write it to disk. I've
    seen things like Madeline and other Prevayler-type things, and they seem
    to want to keep everything in memory and only write snapshots and
    logging to disk. A neat query model and some in-built concurrency
    support (even if it's just read/write locking) would be added bonuses.

    Tim Bates
    --
    id.au

    Tim Guest

Page 1 of 3 123 LastLast

Similar Threads

  1. Running Java applications with CF applications
    By isleta13 in forum Coldfusion Server Administration
    Replies: 2
    Last Post: March 28th, 12:48 PM
  2. Replies: 0
    Last Post: October 21st, 01:26 PM
  3. Replies: 0
    Last Post: August 21st, 12:11 AM
  4. Replies: 0
    Last Post: August 15th, 09:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139