New Extra: ExtraBuilder? Beta version to test

I installed the new version and the installation works fine now.

However, there is probably a bug in the new functionality “Add Existing Tables to Package”.
I created a new table in the database with a column id (primary key, auto increment) and when I added the table to the package and looked at the schema, it looked like this:

<object class="Test" table="test" extends="xPDOSimpleObject">
	<field key="id" dbtype="int" precision="10" phptype="integer" null="false" default=""/>
	...
</object>

As the class “xPDOSimpleObject” already has a built-in, autoincrement field named id, there shouldn’t be another field id.

It also seems, that the created object always extends “xPDOSimpleObject”, even if the table has a primary key with a different name (or no primary key at all). Maybe it is a better idea to default to extend “xPDOObject” (and only change it to “xPDOSimpleObject” if there actually is a field id in the table).

1 Like

I’ll see if I can get at least a short walk through done this weekend.

1 Like

I’ll double check that functionality. I’m a little fuzzy on SimpleObject vs. just Object and when you would use which. I do see in the reverse engineer script where they are handling fields with primary keys. I’ll take a closer look there.

Tried to keep it short, but I kept rambling for 40 minutes :slight_smile:
Feel free to fast play or skip through.

3 Likes

That’s fantastic @jaredfhealy. I really like this approach.
Thanks very much for taking the time to do the walkthrough!

1 Like

The latest build 1.0.5-beta is below and should correct the issue.

https://github.com/jaredfhealy/extrabuilder/blob/99bd6e249d22c068febfce948f2086166f5e019f/_packages/extrabuilder-1.0.5-beta.transport.zip?raw=true

I incorporated the same logic they had in the reverse engineer script. When I first looked at it I removed that for some reason. I added a couple fields to the object table to track “extra” and the “generated” tag that is added.

I tested the newest version and still had some issues with the import of existing tables:

  • If a table has a different primary key than “id”, then this isn’t recognized.

The problem could be that after this line in the code

$Key = $this->getIndex($Key);

the variable $Key isn’t used anywhere. (I could be mistaken. I haven’t look at the code that closely.)

  • Another thing I noticed is, that the attribute ‘unsigned’ is correctly saved to the table modx_extrabuilder_fields, but never shows up in the schema that is generated.

@jaredfhealy thanks for making it available through modx package provider. Did i miss an announcement :wink: ?

@raffenberg Yeah :slight_smile: , I was headed out on a trip and traveling for a month. I wrapped up the main issue that @halftrainedharry posted where it wasn’t properly outputting the “unsigned” attribute. The other issue I think is minor, but is on the list to fix.

Since I was going to be gone and busy with work, I went ahead and published it. I’ll be back next week though and plan to post an official announcement along with some documentation.

Travelling for a month sounds good :+1: It seems i have far to much categories, i still have to “hack” the getcategories processor .-)

@jaredfhealy Just want to say thanks for what looks like a very useful tool! I’m a longtime MODX user but I’ve always wanted to dabble a bit more in the CMP / custom table world and this tool is the best I’ve seen yet. Only been playing with it for a few hours.

Thanks so much for your time and efforts on this!

@robcarey You’re welcome! I appreciate the feedback.
I need to work on the documentation some more and provide some examples :slight_smile:

1 Like

Precisely the feedback I would/should have provided. I’m also aware though that we all have only so many hours in the day :slight_smile:

Definitely looking forward to watching this extra evolve.

Hi All

Just reopening this again with what is hopefully a simple query.

I am trying to create a field that has a unique column that is not the “ID” field.

Is there anyway i can do this with the current inplementation. I can see it has an index option which i have set to “btree” but the outputted schema always has “unique” set to false

<index alias="stringkey" name="stringkey" primary="false" unique="false" type="BTREE">

That’s a little bit of a gap and where you would rely on the “Raw XML” field on the object record. As an example I looked at the MODX schema for an object that extends “xPDOObject” instead of simple object which has the ID field automatically added. I just used part of the full schema and then the “Import Schema” feature and pasted it in.

<model package="modx" baseClass="xPDOObject" platform="mysql" defaultEngine="InnoDB" phpdoc-package="modx" phpdoc-subpackage="" version="1.1">
	<object class="modActiveUser" table="active_users" extends="xPDOObject">
		<field key="internalKey" dbtype="int" precision="9" phptype="integer" null="false" default="0" index="pk" />
		<field key="username" dbtype="varchar" precision="50" phptype="string" null="false" default="" />
		<field key="lasthit" dbtype="int" precision="20" phptype="timestamp" null="false" default="0" />
		<field key="id" dbtype="int" precision="10" phptype="integer" null="true" />
		<field key="action" dbtype="varchar" precision="191" phptype="string" null="false" default="" />
		<field key="ip" dbtype="varchar" precision="20" phptype="string" null="false" default="" />

		<index alias="internalKey" name="internalKey" primary="true" unique="true" type="BTREE">
			<column key="internalKey" length="" collation="A" null="false" />
		</index>

		<aggregate alias="User" class="modUser" local="internalKey" foreign="id" cardinality="one" owner="foreign" />
	</object>
</model>

After importing, if I use the “Preview Schema” you can see that I’m not properly bringing in Indexes and there is none for “internalKey”.

I knew that there would be scenarios where other variations were needed though so I included the “Raw XML” field on the Object record. You can leave the “Index” field selection set to none.

Then on the Object record Raw XML just drop in the index needed.

When you preview the schema output now, that index should be included with your object.

I don’t see how we can use “Strike through” styles on the editor. So I just removed my previous statement. For some reason I thought you could only have unique index on the table and that you would need to extend xPDOObject. But that’s wrong :slight_smile:

Anyway, this should allow you to add any xml to your object/table output. And if a feature is missing you need on a specific field, you could even past the field in here as XML rather than creating it. Whatever works better for your flow. Or if you had a common set of fields you use a lot, paste them in here, and only add the unique ones from the Field section.

Hope that gives you what you need!
-Jared

Cheers for the very thorough breakdown, i completely missed the “raw xml” section, most likely once I went past the object creation and onto fields, I never really looked back at it.

This will most likely serve what i want it to do nicely. So I could create the index the normal way (via the form), get the syntax from the preview (as it created the index code for me with unique set to false) copy that into the raw xml field and make my changes, then go back to the field (the form method)and remove any indexes to that field i added there.

Exactly. It’s a little bit of a work around. I’ll see if I can include an update for that in the latest version. I’ve been working on compatibility for Modx 3.

2 Likes

Good to hear :slight_smile:

I have held off on installing modx3 for production sites atm because i imagine a ton of compatibility issues in its first few months upon official release. Good to see you are looking to the future with this extra because it is really a game changer IMO

1 Like

Is there any chance you could clone a site and upgrade it to MODX 3? The more people that do this and figure out what’s working/not working in terms of core and Extras the better the release will be. If everyone decides to wait and few people test it with real world sites (out of the public eye) it’s going to take longer and be more painful a transition.

I will see if i can find some time to do that, unfortunately i work for a company with really strict deadlines so i can’t upgrade a CMS just to test if something works while on work hours :frowning: . So its more of a case of, use what is production ready now.

When I get some downtime (outside of work) i will definitely give it a go. On a different point I have another query.

When creating a field or an object is there anywhere where i can define the collation type? or is this something i would do in the raw xml also

Edit: on looking at it again, im going to assume it inherits the collation from the database itself instead of it being defined in the components schema. Correct me if im wrong. I just manually updated the entire database and all columns to use utf8 over latin_swedish