Illustration or tutorial showing 'multi-schema' mode in DBIx::Datamodel

[Ted Byers]

Is there such an example?

In actuality, I am after a bit more.  I am just coming to examine DBIx::DataModel, and it does look very interesting.  However, as the author of the document points out, there are other ORMs available.  Before I put a lot of time into studying this particular ORM, I'd like to get a sense of the extent to which it gets me where I want to end up.  Thus I have two main questions.

1) Am I right in interpreting the little that has been said in the documentaiton about 'multi-schema' mode that that means I can have two (or more) databases, possibly in different RDBMS on different machines, and, by creative use of this ORM, write middle tier code as if the two databases as if they were one database?  If so, that brings a much needed flexibility and performance enhancement to one of my applications.

2) To what extent does this (or any other ORM) support distributed caching, such as is available with memcached?  At the moment, I am exploring options WRT creative use of multiple server clusters and their potential for both performance enhancement and fault tolerance (focused more on fail safe rather than safe fail objectives).

In truth, I would be surprised if any ORM provided everything I am interested in, but if there were a small suite of packages that together provide it all, and that play nicely together, that would be good.

I'd appreciate both pointers to something like a tutorial on the one hand, and suggestions for other packages to examine that, whether alone or with this ORM, may take me closer to my objective.

Thanks

Ted

[Ross Attrill]

Ted - I am not sure about your specific questions. However, my
experience of DBIx::DataModel (DBIDM) is that it is extremely well
thought out and put together. I have worked with a variety of ORMs
including JPA/Datanucleus in Java, DBIx::Class in Perl and Sequel in
Ruby. Sequel in Ruby is excellent but DBIDM trumps all of them.

I suggest start using it in single schema mode and perhaps set up two
single schemas in DBIDM for your two databases. You could then use
plain old Perl to merge results from your separate RDBMSs.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "dbix-datamodel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dbix-datamode...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Laurent Dami]

Le mardi 14 janvier 2014 21:03:20 UTC+1, Ted Byers a écrit :

Is there such an example?

In actuality, I am after a bit more.  I am just coming to examine DBIx::DataModel, and it does look very interesting.  However, as the author of the document points out, there are other ORMs available.  Before I put a lot of time into studying this particular ORM, I'd like to get a sense of the extent to which it gets me where I want to end up.  Thus I have two main questions.

1) Am I right in interpreting the little that has been said in the documentaiton about 'multi-schema' mode that that means I can have two (or more) databases, possibly in different RDBMS on different machines, and, by creative use of this ORM, write middle tier code as if the two databases as if they were one database?  If so, that brings a much needed flexibility and performance enhancement to one of my applications.

Hi Ted,

 

Multi-schema mode is useful when you have several databases that share the same structure, and you want to access them simultaneously. A typical example would be when you want to transfer information between a development database and a production database : your transfer program opens two schema instances, does the selects on one side and does the inserts on the other side. The advantage is that you can talk to several databases simultaneously; the disadvantage is that the schema object must be passed as parameter to every subroutine or package that needs to access the database (very similar to a $dbh at the DBI level), whereas if you work in single-schema mode, the schema and tables are just classes that sit in the global namespace, so they are accessible from everywhere.

 

DBIx::Class, which is the main ORM used by the Perl community, doesn't have a notion of "single-schema mode"; it is always in multi-schema mode, by design.

 

Multi-schema doesn't mean that you see the whole thing as one single database; so you cannot perform joins between tables on one side and tables on the other side. For that kind of functionality, I would recommend to use database links at the RDBMS level, not at the application level.

 

2) To what extent does this (or any other ORM) support distributed caching, such as is available with memcached?  At the moment, I am exploring options WRT creative use of multiple server clusters and their potential for both performance enhancement and fault tolerance (focused more on fail safe rather than safe fail objectives).

To me, distributed caching is an issue orthogonal to ORM, and I don't know of any ORM that implements that. I think you have to choose your ORM, choose your caching technology, and then it's the job of your program to assemble the whole thing (which shouldn't be too hard, by the way).

 

 

In truth, I would be surprised if any ORM provided everything I am interested in, but if there were a small suite of packages that together provide it all, and that play nicely together, that would be good.

I'd appreciate both pointers to something like a tutorial on the one hand, and suggestions for other packages to examine that, whether alone or with this ORM, may take me closer to my objective.

Thanks

Ted

 

Choosing an ORM is a complex task, but it's worth investing in choosing the best tools for your needs, instead of blindly following whatever is fashionable at the time you start your project.

I hope you will choose and enjoy DBIx::DataModel !

 

Cheers, Laurent Dami