On Wed Jan 29 20:04:58 2014, TSIBLEY wrote:
Show quoted text> On Wed, Jan 29, 2014 at 06:24:32PM -0500, Ivan Kohler via RT wrote:
> > <URL:
https://rt.cpan.org/Ticket/Display.html?id=83035 >
> >
> > On Tue Jan 29 14:45:03 2013, TSIBLEY wrote:
> > > This causes variations in returned schemas when running under perl
> > > 5.17.6,
> > > which randomizes the hash-key ordering much more aggressively.
> > > Just like
> > > DBIx::DBSchema::Table->Columns, the DBIx::DBSchema->Tables method
> > > shouldn't rely on the keys() built-in to return the list of tables.
> > > At
> > > the very least, it should get a sort() wrapped around it. Ideally
> > > the
> > > tables would be sorted by the order in which they were added, like
> > > columns, but that requires a little more change.
> >
> > I'm not sure I agree completely?
> >
> > Databases don't have a concept of "table order", right? Tables in Pg
> > or MySQL (etc.) aren't in any sort of order (creation order or
> > otherwise), as far as I know. That's what we're trying to model.
> >
> > So, IOW, perhaps the new hash key randomization is just making more
> > obvious what should have been true all alone, that tables have no
> > inherent ordering?
>
> This isn't about inherent ordering from the database-level.
I believe it is relevant. Our objects attempt to model database schemas. Database schemas don't have table ordering. Objects you reverse-engineer from an existing database schema using new_native / new_odbc don't have any sort of table order.
So I'm not feeling like objects you instantiate yourself, manually in perl code should have some sort of magic "table order" that's lost when you use those objects to create an actual database. (as a supported external API)
Show quoted text> When I wrote "Ideally tables would be sorted in the order in which
> they
> were added, like columns," I meant added to the DBIx::DBSchema object
> via the constructor, which takes an ordered list.
It does, but it makes no promises to preserve that order, and I don't believe it should for the reasons above.
Show quoted text> If you look at the Columns method on ::Table you'll see that it
> preserves the order from the constructor call.
Column order is part of the actual database schema, though.
You could make an object, use it to create the actual database schema, then reverse engineer that schema, and you would have same order, right?
The same is not true for tables. You can't make some table objects, use them to create the actual database schema, then reverse engineer that schema and get the same order back.
Show quoted text> The Tables method could do the same thing.
It could, but I don't think it should, for the reasons above.
Show quoted text> On the other hand, you could just wrap the keys() in a sort() and be
> done with it.
I think the code which uses the ->tables method should do this if it wants tables in a deterministic order.
Show quoted text> > I'd be interested in more background / hearing why this was a
> > problem.
> > A now-failing test somewhere in a module that uses DBIx::DBSchema?
> > That seems to come up a lot with those changes. Or something more
> > applicable to non-test usage?
>
> Tests only, IIRC. That said, as noted in the linked Referred To By
> ticket on rt.cpan.org, the DDL generated for a schema object will
> change
> from call to call, and hence table creation order will change.
> Creation
> order may matter if one table defines a relationship to another.
It may, but we should probably solve the actual problem if and when we get to it?
Something similar actually came up with the new Foreign Key support and it was better to do the basic creation/changes first and define relationships next. Trying to order the table statements didn't work (easy for a schema to have unsolveable cyclic relationships).
