Hi Jeff et al.,
Schemas should be in Enterprise Architect whenever possible, in docushare
otherwise. I understand that UW has some issues with the SQL generated by
EA, so if an exception needs to be made, at least there should be a link to
the schema within Docushare. There is a collection in Data
Yes, Russell has had to spend a lot of time 'repairing' the SQL that is
generated by EA. This part of EA seems to be less robust than the UML
we've been using for the rest of the project. EA has been good about
responding to our bug reports and claims that the next release of EA will
have improved functionality in this area - they admit that they still have
some work to do. Sounds like they are willing to improve the database
section in a timely fashion - some of the bugs we reported have already
been addressed as they work on the latest version.
Creating the UML in EA for databases is straightforward and relatively
simple to do. I see no issue with creating a merged schema in EA.
Perhaps by the time we have converged on a final schema, a lot of the
major issues we have encountered with EA's SQL generation will be
resolved.
(With regard to the EA SQL issues, we need them documented so that we can
forward them on to EA support.)
I have compiled the bug reports we have sent to EA along with our notes on
EA's database issues. Russell has added this list to our unsecured
database link here:
http://www.astro.washington.edu/rowen/LSST/EABug_bullets.txt
Unfortunately this list is a little incomplete. EA's bug reporting form
is web-based and does not generate a copy of the report. We unfortunately
were not very good about keeping notes on all of the little issues we
found/reported. The ones in this list are certainly the more agregeous
bugs/issues. We will continue to update this list as we trip across other
bugs and issues with EA's SQL generation.
As a reminder - our database schema can be found here:
http://www.astro.washington.edu/rowen/LSST/DBDocs/UWDatabase.html
Please feel free to add these links to the docushare or plone (or anywhere
you see fit).
Nicole
_______________________________________________
LSST-data mailing list
[email protected]
http://www.lsstmail.org/mailman/listinfo/lsst-data
