Let me just say that I'm not a database guru or anything. I know how they
work etc but I don't know the inner workings of the BEASTS.
What we currently have is a product that is similar to castor in that it can
save objects to a relational database. It uses a mapping file like castor
does; however it's not as 'pretty' as castor is. It does however create
tables etc automatically for you and is why I would like to see if it could
be added to castor.
I totally agree with your points and I believe for the most part the
model/schema will already be defined by the application that you are working
on. However there are times that perhaps a component may want to store
things using castor into a database. We won't know the database it's
configured at runtime.
Examples:
We have a scheduler and we want to store our scheduled jobs into a database
using castor.
OR
A simple properties list stored by user id that a component wants to store.
We would have to write our own code to create all the tables etc for all the
databases supported. Every component that wants to do it would have to do
this.
So I was thinking more of a runtime thing were components may want to store
things into the database that a customer has already configured. If tables
don't exist create them. Also people would have to realize that the tables
created would not be optimized to the best they could.
--ekiM
Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht
oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist
and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you
can sitll raed it wouthit porbelm. Tihs is bcuseae we do not raed ervey
lteter by it slef but the wrod as a wlohe.
-----Original Message-----
From: Gregory Block [mailto:[EMAIL PROTECTED]
Sent: January 23, 2006 8:27 AM
To: [email protected]
Subject: Re: [castor-user] Creating database tables from XML Mapping file
On 20 Jan 2006, at 18:38, Ralf Joachim wrote:
> It's simple but will require quite some time to implement. I think
> with
> the planned refactoring of SQL generation we should also take care to
> include this featur.
I'm going to have a punt, with a big IM(notashumbleasitshoulddbe)O
attached to it, and say the opposite:
- Databases are uniquely ugly beasts, at their prettiest. Each
database will perform best when its owners spend time thinking about it.
- Table generation will require additional hurdles in syntactical
differences between databases
- Then we've got to regurgitate foreign key constraints...
- Then we have to cover index building, and under what
circumstances the system would need indexes...
etc.
I've got to be honest here: A lot of people spend a lot of time
maligning the performance of things like Hibernate, and never once
stop and look to see whether or not they're doing things that their
DBA would flat out shoot them over; they expect the software to be a
replacement for a DBA.
It won't be. It can't ever be. It won't make half as good a set of
decisions.
The power of Castor is in it's flexibility; our ability to strap on
just about any SQL schema and get a useful object hierarchy out of
it. If the optimal implementation of my object hierarchy conflicts
with my optimal data representation, that's for my DBA to solve
through views, calculated indices, and whatever other tools my DBA
has available.
So, in reality, we'd only ever get as far as the first step - maybe
also foreign key constraints. But we'd be forever neck deep in bugs
akin to "this doesn't work on database version X" and "my performance
sucks because I generated db schema" mail. Ultimately, the best
thing about mapping, and a lot of people aren't going to agree, but
hey, that's life, is that it requires people to think about the way
they're structuring their data. If someone goes and creates a bunch
of text flags, and stores them all in a varchar instead of using a
foreign key to another table, he's going to take it on the nose.
When forced to look at how the data is being stored, your average
programmer *will* think "I'm spending an awful lot of disk space on
attaching the word "PENDING" to a new row in that table, maybe I
should be using a lookup table for that.
We shouldn't try to solve this problem in Castor - leave the domain-
specific knowledge of databases to DBAs whenever possible, IMO. We
do a really good job now of covering just enough of the hurdles to
get data into the system in a smart way, without having to cross the
line into the actual data structuring role; IMO, it's best to leave
it that way - leave the domain specific knowledge to those who have
it, rather than trying to replicate a miniature DBA in code.
And if someone really that desperately wants to avoid learning CREATE
TABLE... then they're never going to be happy with the product,
because they're never going to be able to understand why some things
are fast in a database, and why some things aren't - and will do
exactly what most of the people with a negative opinion of Hibernate
do: say "its performance sucks" and walk away, without ever once
having to rub two brain cells together in the hopes of making a
fire. :)
But that's just me. :)
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
