Subsonic Renames a Table Named "Media" to "Medium" - subsonic

I have a table in my SQL2005 DB named MultiMedia - after DAL generation with SubSonic v2.2, the classes that are generated are named "MultiMedium". The table was originally named Media and this resulted in classes named Medium as well - easy enough to change the name of my table at this point in the project, but wondering if anyone else has run into this and from the team's perspective, is this a known issue? What other naming problems might I run into as changing table names will not remain inconsequential for long.
Thanks!

I get one of these about once every 6 months :) - they're hysterical :). Yes - we do change Octopus to Octopi ... our inflector is pretty rad.
Anyway - you can set fixPluralClassNames to false on your provider - it will change this:
https://web.archive.org/web/20090524072848/http://subsonicproject.com/configuration/config-options/

Related

Liferay 7.3 - Auto upgrade of custom services

I have a custom service module (myproject-service & myproject-api).
With Liferay 7.2 and previous versions, when I changed my database model (for exemple : add a new column in a table in the service.xml), I used an UpgradeProcess and an UpgradeStepRegistrator, with an incrementation of the Liferay-Require-SchemaVersion.
Since the 7.3 version, the autoupgrade has been moved to a property and changed to false value. In developpement, this value is true and everything works fine but in production, my custom service doesn't upgrade now at server start.
Is there a solution to make this system works again automatically ? I've seen that now we have to do the upgrade manually in the gogo shell with upgrade:execute command.
You are probably looking for
Set this to true to execute the upgrade process when the portal starts and modules are activated.
upgrade.database.auto.run=false
You still need to build the "upgradeProcess", as in:
https://help.liferay.com/hc/en-us/articles/360018162851-Creating-Data-Upgrade-Processes-for-Modules-
Technically, you could activate the same property in production systems. However, this is neither safe, nor performant: The solution for table updates is generic and (as far as I know) will
export your table's data,
DROP TABLE,
CREATE TABLE (with the new structure)
populate the table with the previously saved data.
Now, apart from this being horribly slow for large amounts of data, there are some other shortcomings:
if you have renamed a column, or
added a non-nullable column,
this would fail to do the work as you expected it (even in development).
Further:
If this process is interrupted at any time, you might lose all of your data
In many cases, a simple ALTER TABLE xxx ADD COLUMN yyy would be sufficient, and is quick, safe and easy to do within SQL. That's where your UpgradeProcess kicks in. You wouldn't want to do that after every little bit in development (hence the property), but you certainly don't want to DROP TABLE with important data in production, and wait for who-knows-how-long, when there was just a trivial change.
From that point of view: You want to write a custom UpgradeProcess, even if you don't know that you do. And there's even a great starting point, that takes away the repetitive and low level work.

Akeneo 2.1.4 : How can I change an attribute type?

I have an attribute of type pim_catalog_number, but I need to change this to pim_catalog_simpleselect. I cannot change this in Akeneo and if I try to overwrite it by importing a new attributes-file I get the notice that I am not allowed to change the type.
But I have a scenario where I need to do this. So what's the proper way to do this? I can imagine doing some direct SQL queries, but what are the consequences of changing the type directly in the database?
For now the only solution is to export the product values, delete the attribute, create the attribute with the right type and then re-import the products.
We are currently working on a proper solution to do that, but with all the feature of the PIM involved (history, rules, proposals, search, etc) it's not an easy task. We dedicate 1 dev full time on this task for the next three months to come up with a nice solution.

Microsoft Dynamics CRM 2011 best solution to change entity's field data type

I'm having an issue on changing data type of a field in Dynamics CRM 2011 On Premise deployment.
In my managed solution, name it "Solution 1", I have a custom field in contact entity: "new_usernumber" of type number (int). I want to change it to string as per new client's requirement (for new users they want to add prefix to it).
I can uninstall the solution and deploy the new "fixed" managed solution, but this requires me to delete the value on my custom fields. Is there any better solution for this?
TIA
There is no easy way to do this. If you don't already have data deployed in the instance using the managed solution I recommend deleting it and importing a corrected managed solution file.
There is no supported or unsupported process of changing the data type(or logical name) of a field without data loss. What you will need to do is add the new field and then write a quick update utility to copy the data from the old field to the new field.
Here is a great article on exactly how to pull off deleting a field in a managed solution. Note, if you are trying to preserve data you'll need to run the update after the step "Import devkeydetDeleteExample_1_1_HOLDING.zip"
Have fun...this is a pain, but certainly doable!
A few months ago I recreated fields in a solution (from double to int). That was a huge mistake. I'm still not sure where things went wrong but they did go wrong. Not only did I lose the date. I managed to introduce errors in the meta-layer so our MVP had to sit dear help me get it running again. He wasn't happy. I wasn't happy. The customer wasn't happy (ex-customer today, mostly because of that).
So, my humble advice - don't do that. Declare a new field instead. If you have usernumber, keep it but start using userNumberString (or userString, userName etc.). My guess is you'll keep your hair longer that way.
And if you manage to succeed, please do tell. :)

Xcode4: two entities with "required" relationship ... failing to be maintained by Core Data?

EDIT: might be fixed in latest Xcode 4.0.2 (just released) - I'm downloading this out now, and will re-edit once I've tested it.
Create two entities (call them "Manager" and "Employee", to stick with Apple's docs).
Create a relationship, "worksFor" from Manager (1) to Employee (many), and mark it as "not optional". (you'll probably need to create 2 relationships, mark 1 as inverse of other)
Hook up an interface using IB, according to Apple's original docs (NB: these don't work any more, but here's an almost exact recreation of the basic setup in Xcode4: http://rgprojection.blogspot.com/2011/04/xcode-4-and-core-data-macos-x.html) and use Bindings (as described in the linked post) to create/add/delete the objects.
Now try to save. ERROR: "worksFor is a required property".
In previous versions of Xcode, this worked as expected: you'd told Xcode that there was a bidirectional relationship, you told it that it was required, and so when it added the "Employee" to the "Manager", it automatically hooked-up the inverse.
Has anyone else worked out how to make Xcode4 do what it's supposed to? Is it an Xcode4 bug? I know that some of the CoreData support in Xcode4 has been deleted, with no replacement (yet), so I'm wondering if this has been deleted too?!
EDIT: here's another project, one I made from scratch, same problem. Although (xcode4 bug, definitely!) this time I created the Relationship in the "grid" editor view rather than the "tree graphical" view... and the generated source code for objects was different (should not be the case, obviously)
second project screenshot
EDIT2: StackOverflow was showing the screenshot above, but has now removed it, you'll have to click on the link. Sorry.
I haven't seen the problem you describe and I've created several data models under Xcode4. It appears to work just like it did in previous versions in that regard. I think you've got something else going on.
Xcode 4.0.2 seems to have fixed the problem - everything works as expected now, with no changes to code :)

SubSonic Include Tables Alternative to Exclude

SubSonic is great and helps me code a lot faster, but now I've run into something that I think would help a ton of programmers.
I'm programming against a huge database, but only need about 6 or 7 tables out of the 50 or so tables. The exclude in the Settings.ttinclude requires me to enter the other tables not needed. I would love to have a IncludeTables string array that speeds up the entry of the tables that are required for the application.
Hopefully the team at the SubSonic project already have a patch/fix for this.
[Edited]
I see that v2.2 has includeTableList and whole list of other configuration options. Where do I set these in v3.0.0.2???
I'm no SubSonic expert but if you are using the ActiveRecord t4 templates, you can just edit the template itself.
Look in SQLServer.ttinclude:
const string TABLE_SQL=#"SELECT *
FROM INFORMATION_SCHEMA.TABLES";
Just add a WHERE clause to the above to include only the tables you want.
Sestocker - Thanks for that... I believe that would work, but I have the solution that I want:
In the Settings.ttinclude I have a IncludeTables variable below the ExcludeTables variable:
string[] ExcludeTables = new string[]{
....
};
string[] IncludeTables = new string[]{
....
};
Then I updated the ActiveRecord.tt and Context.tt, changing the code that checks the ExcludeTables:
if(!ExludeTables.Contains(tbl.Name))
....
to this
if(IncludeTables.Contains(tbl.Name))
....
so I made sure that any reference to the "!ExcludeTables" was changed to "IncludeTables".
It generated the classes I needed, but I have not tested it yet.
I'll see if I can work on the t4 templates a bit to have the code work with both Exclude and Include and see if I can post it online later today or tomorrow.
The goal of having T4 templates is so you can do for yourself - not ask us to fix it (not that we mind honestly - but it's easier for you). In this case most people have just a few tables they want to exclude.
That said, in the next rev I'll make the method more generic so you can change it as needed (rather than check an array - I should ask "ShouldGenerate()").

Resources