In attempting to port a mysql-based game that uses a
large number of
unsigned fields, I noticed that AXMLS didnt mimic the
unsigned
designation when doing an export/dump of the existing
database.
Several months back, adodb did add support for unsigned
in datadict
(on multiple db's), so the hooks are there for axmls to
use.
Am I correct that AXMLS doesnt currently support
unsigned, and if so,
is there a different workaround than a hardcoded
alter-table call for
every column that is unsigned?
I used the alter-table work around for the
type-of-a-table/tabopt
problem, but I'd really rather not keep embedding
schema info in code.
Logged In: YES
user_id=345539
You can create an unsigned field by adding opts="UNSIGNED"
to the field element as shown below:
<table name="test_table">
<field name="test_field" type="I" size="11" opts="UNSIGNED">
<KEY/>
<DEFAULT value="0"/>
</field>
</table>
I have tested this with adodb 4.52 and axmls CVS, but it
should work fine with any recent release of adodb.
Dan
Logged In: YES
user_id=528997
Hmm. I guess it should have been two bugs - one for doing it
manually, and another for the detect/export bug.
I'm overjoyed that there is a way (glad to be wrong!!!!),
but it still doesnt do the export correctly - on a mysql
table with unsigned columns, it doesnt export them as
unsigned - it makes them "default", which is signed.
Any solution for that half of the problem?
Logged In: YES
user_id=345539
Glad to have been able to help out with at least 1/2 of the
problem, unfortunately I get the feeling the other 1/2 won't
be so easy.
The Datadict hooks for unsigned values are what axmls uses
to create unsigned fields, as far as I can tell there are no
hooks in the ADOdb MetaColumns function to pull this data
out of the database.
Looking at the ADOdb MySQL driver it should be fairly
trivial to add UNSIGNED support, at least for MySQL. Once
ADOdb supports it then adding support in axmls becomes a
trivial exercise.
I will put together a set of patches as soon as possible,
though I can't say for sure how quickly I will be able to
get to it.
Logged In: YES
user_id=345539
Ok, I have added 'proper' unsigned support to axmls, you can
now add an empty element <UNSIGNED/> to a field in the same
manner as KEY, etc.
I have submitted a patch for the mysql and mysqli ADOdb
drivers to John Lim, once it makes its way into the release
the unsigned attribute will be fully supported for both
insertion and extraction.
Logged In: YES
user_id=528997
Fantastic! Couldnt have asked for more.
Looking forward to the next release!!!
Logged In: YES
user_id=528997
Or not..
In testing the latest cvs, pull as of 9-10-04 (rev. 1.9 of
xmlschema.dtd), its unable to create a table.
Note - I dont mean "it cant create a table with Unsigned in
it", I mean when I update adodb452 with the current cvs from
axmls, the creation of a standard mysql table fails.
ie, include adodb-xmlschema.inc.php works, include
adodb-xmlschema-new.inc.php doesnt.
I've tested on multiple tables, multiple setups, and its
completely consistent.
Is current CVS of axmls unusable UNTIL the new adodb
mysql/mysqli drivers come out? From the phrasing, it sounded
like it would be functional, but wouldnt make unsigned.
Logged In: YES
user_id=345539
Ok, there could be several factors at play here, so let's
make sure everyone is on the same page.
First, include the line:
define ('XMLS_DEBUG', true );
at the beginning of your script, this will cause axmls to
print debugging information which may help determine the
problem.
Secondly, as of cvs revision 1.51 of adodb-xmlschema.inc.php
the schema version has been updated to 0.3, to reflect the
addition of the UNSIGNED element and the data insertion
syntax. This has several ramifications for processing a 0.2
schema:
1. You will need the new .xsl stylesheet
'convert-0.2-0.3.xsl' present in your xsl directory.
2. You will need to have the xslt extension installed.
You can test that this is working correctly by looking at
the output of:
$db = ADONewConnection( 'mysql' );
$xmls = new adoSchema( $db );
print_r( $xmls->ConvertSchemaFile( 'yourschema.xml' ) );
If this does not display a valid 0.3 schema then you have
found the problem.
Thirdly, it may be an issue related to your environment, if
so please let me know your operating system, webserver and
php details and versions.
Finally, if you wish to email me privately with your schema
and test script I can try to reproduce your problem in my
development environment.
Logged In: YES
user_id=528997
Aha. That was the info needed - I don't have the xslt
extension installed. My dev box matches the deployment
platform that most of the admins that use my code, so I
can't install it.
Can I manually convert my schema to 0.3, so the xslt
transform isnt needed? From the changes in the dtd, it looks
like the changes in schema are fairly limited (unsigned
support being a full element instead of an attribute, etc).
Logged In: YES
user_id=345539
You can either use the ConvertSchema function to generate a
0.3 schema from your 0.2, or just change the schema version
from 0.2 to 0.3 in the xml.
In general a valid 0.2 schema will also be a valid 0.3
schema, so you should be fine.