If it works with XSD, I agree that it's the nicer way to go.  It's more concise and consistent.  Could you add the info to the ticket?
 
Nathan


From: Paul Keeble [mailto:csuml@yahoo.co.uk]
Sent: Sat 8/25/2007 8:41 AM
To: Nathan Voxland; Alan Savage; liquibase-user@lists.sourceforge.net
Cc: liquibase-dev@lists.sourceforge.net
Subject: Re: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

Is it definitely possible to do this, I found in the W3C tutorial the ability to add an "any attribute" statement: http://www.w3schools.com/schema/el_anyattribute.asp

It would allow any possible attribute to be put onto the custom tag, effectively we would be not validating the attributes. Since we could only really check if the attribute was there at runtime this would work anyway. This would also mean we don't need new code for doing the assignments in the SAX parser. I also personally think its neater and more consistent.

There are other things we could do as well - for instance the way ant does custom tasks (declare it, give it a name and then when you find it do the right thing). That is another possibility and for people using a lot of custom changes that might be more compact and obvious. Maybe this isn't an exclusive option, no reason why we couldn't do both. That would look like:

<declareCustom className="com.some.package.MyCustomChange" name="mine1"/>

<mine1 columnName="customer_id" dataFile="data.txt"/>

Paul K

----- Original Message ----
From: Nathan Voxland <Nathan.Voxland@sundog.net>
To: Alan Savage <asavage@prospricing.com>; Paul Keeble <csuml@yahoo.co.uk>; liquibase-user@lists.sourceforge.net
Cc: liquibase-dev@lists.sourceforge.net
Sent: Friday, 24 August, 2007 9:59:09 PM
Subject: RE: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

The question with using the attributes is: can you have design a XSD that lets you do this:

 

<custom className="com.some.package.MyCustomChange" columnName="customer_id" dataFile="data.txt"/>

 

and still validate?  That’s what I thought wasn’t possible, but I’m not a huge XSD expert.

 

Nathan

 


From: Alan Savage [mailto:asavage@prospricing.com]
Sent: Friday, August 24, 2007 3:51 PM
To: Nathan Voxland; Paul Keeble; liquibase-user@lists.sourceforge.net
Cc: liquibase-dev@lists.sourceforge.net
Subject: RE: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

 

I was thinking a separate <property> tag would be easier to read and less prone to mistakes. For example:

 

<property name="dataFile" value="data.txt">

<property name="columnName" value="customer_id">

 

maps to:

 

MyCustomChange.setDataFile("data.txt");

MyCustomChange.setColumnName("customer_id");

 

If we list the properties as attributes on the custom tag, then I could accidentally mix up my properties. For example...

 

<custom className="com.some.package.MyCustomChange" property1="customer_id" property2="data.txt"/>

 

where property1 should have been the data file, and property2 should have been the column name.

 

Alan

 


From: Nathan Voxland [mailto:Nathan.Voxland@sundog.net]
Sent: Thursday, August 23, 2007 8:46 PM
To: Paul Keeble; Alan Savage; liquibase-user@lists.sourceforge.net
Cc: liquibase-dev@lists.sourceforge.net
Subject: RE: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

The trouble with that syntax is that I don't think we could have a .xsd file validate it then, could we?

 

Nathan

 


From: Paul Keeble [mailto:csuml@yahoo.co.uk]
Sent: Thu 8/23/2007 6:06 PM
To: Nathan Voxland; Alan Savage; liquibase-user@lists.sourceforge.net
Cc: liquibase-dev@lists.sourceforge.net
Subject: Re: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

Based on our current implementation I actually think the syntax below will be both easier to implement and neater:

<changeSet id="0001" author="alan">
  <custom className="com.some.package.MyCustomChange" property1="value1" property2="value2"/>
</changeSet>

One thing I would say is before we do this particular change we should define the Life Cycle for a Change a bit better, its a little ugly after the setUp call got added with sqlfile and by exposing this the API is going to get locked in for a good deal of time.

Paul Keeble

----- Original Message ----
From: Nathan Voxland <Nathan.Voxland@sundog.net>
To: Alan Savage <asavage@prospricing.com>; liquibase-user@lists.sourceforge.net
Sent: Thursday, 23 August, 2007 8:36:03 PM
Subject: Re: [Liquibase-user] Suggestion for tracker 1756250 - support optionalproperties for custom change implementation

I think that seems like a good idea.  I'll add your response to the
ticket so it doesn't get forgotten when it comes to implementing it.

Nathan

-----Original Message-----
From: liquibase-user-bounces@lists.sourceforge.net
[mailto:liquibase-user-bounces@lists.sourceforge.net] On Behalf Of Alan
Savage
Sent: Thursday, August 23, 2007 2:18 PM
To: liquibase-user@lists.sourceforge.net
Subject: [Liquibase-user] Suggestion for tracker 1756250 - support
optionalproperties for custom change implementation


Hello,

I noticed tracker 1756250 will add support for custom "plug-in"
refactorings. I'd like to offer the following suggestion. Can LiquiBase
support an optional list of property {name, value} pairs for supplying
properties to the custom change plug-in? For example:

<changeSet id="0001" author="alan">
  <custom className="com.some.package.MyCustomChange">
    <property name="property1" value="value1"/>
    <property name="property2" value="value2"/>
  </custom>
</changeSet>

The <property> tags would result in the following calls to my custom
change implementation:

MyCustomChange.setProperty1("value1");
MyCustomChange.setProperty2("value2");

The above would allow my developers to reuse a custom change
implementation, varying only the properties for a given  change set. For
example, a property could be the name of a file that contains data for a
refactoring.

Would the above be a useful addition to LiquiBase?

Thanks,
Alan

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/liquibase-user

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Liquibase-user mailing list
Liquibase-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/liquibase-user





      ___________________________________________________________
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  http://uk.promotions.yahoo.com/forgood/environment.html


The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. Thank you




For ideas on reducing your carbon footprint visit Yahoo! For Good this month.