User macros - where are stored in the DataBase? Macro change via DB or Groovy.

[Rafał Żydek]

User macros - where are stored in the Database?

Case: Automate / speedup user macro code change.

I think we have two possibilities:
-one can be direct change on DB level and clear the cache,
-second can be prepare groovy script to do that. Right now I'm not familiar with classes and interfaces that I need to use it to achieve it.

[David Pressley]

To the best of my knowledge @Rafał Żydek the contents of the entire macro facility are stored in the BANDANAVALUE field where the BANDANAKEY is 

atlassian.confluence.user.macros

This query will help:

select * from bandana where bandanakey like '%atlassian.confluence.user.macros%' ;

 You'll notice that every single macro you've created is stored in a single database field. Ours happens to be a 2.81MB string that is a ton of fun to deal with.

I am not sure what triggers an update of the macro facility, we are having trouble updating the value of BANDANAVALUE and then being able to render them in the interface. I was looking for the same answer and stopped off here to try to be helpful. Please let me know if you've been able to solve for this without shelling out to a paid plugin... 

[Nic Brough -Adaptavist-]

In the database.

So forget it, you won't be deploying them to your install via the database.  Clearing the cache won't work here, these are structural (clearing the cache often doesn't work anyway), and you'll need to trigger a full re-index of Confluence for some types of macro.

You're not going to speed up macro code deployment this way.

[David Pressley]

I think given the context provided further in the question, the OP was asking about the specifics of *where* in the database the macros are stored.

[Nic Brough -Adaptavist-]

Yes, but there's the deeper question of "why"?  We should always think through that before giving someone an answer if it could lead them down a bad path.

In this case, the question contains the answer to "why" - the poster is trying to automate / speed up macro code change.

There's nothing wrong with that idea, but they've suggested a terrible way to do it that simply won't work.  If I were to just tell them what table it was, they'd run off, write a pile of code to make their changes, and probably damage their Confluence installation by running it.  (Yes, even if it's just changing the scripts/code that make up the user macros, the script would also need to stop Confluence while it changes stuff, and then re-index it all after restarting - clearing the caches won't cut it)

A groovy script with one of the scripting apps will work, and it won't need Confluence offline to do it.  Nor does it need any knowledge of where the macros are in the database!

The last time I tried to edit a macro with a script, I seem to remember it used https://docs.atlassian.com/atlassian-confluence/6.6.0/com/atlassian/confluence/tinymceplugin/rest/entities/Macro.html

[David Pressley]

They are probably professionals, same as you and I, so addressing the existential "why" or "why not" isn't my concern.

Is it a bad idea to address the database directly? Yeah. Most of the time. But perhaps they are simply trying to create a development environment that has parity with their current stack of production macros so they can do testing in an environment that has no impact to production, and just want to update a single 2.81MB value for the bandana value field. Or maybe they have another reason I don't care to know about. But I can give them the answer that I've stumbled on and they can do with it as they please. The sooner they realize the approach won't work and can seek validation from the community, the sooner they can learn Groovy and do it the right way. I know I've spent far too long trying to make it work before stopping by here...

Updating and restarting, re-indexing, clearing cache, incantations, and woo-woo doesn't work for us either. Nor does the ScriptRunner macro tool, which we were hopeful would work

Groovy: I can dig it. Thanks for the redirection!

[Nic Brough -Adaptavist-]

I just think it's better to get the "don't look at the database" message out to people who might well be new to this as soon as possible in their journey.

Most of my consultancy has been about asking for the "why" to get a better answer to the question, it's baked into my mindset.

I don't think it's a good experience for people to find out that that way lies madness by making all the effort to do it and have it fall over, then end up finding stuff they didn't know they needed to read earlier!

But, yes, I completely agree with you, of course.

Although, I'm curious, as an Adaptavist - what part of the SR macro tool is not working for you?  (Sorry @Rafał Żydek - this is probably going to be a diversion away from your question if the thread continues)

[David Pressley]

oh, it's not so much the SR macro tool itself, it's that we have a few macros which are embedded in yet-another-plugin (Confiforms), and there are incompatibilities between them. This gets to the heart of my biggest complaint about this marketplace approach. While each one may be required to adhere to the Atlassian standards, they still each have their own nuance, and trying to integrate them all is a fool's errand and a patchwork quilt held together by heroics, old sticky bubble gum, and 6-pack can holders. The effort we have put in to managing the plugins at scale, could have been spent rolling our own application.

On the whole, ScriptRunner has been a lifesaver though, but we are working through a ton of tech-debt, tilling our own grave to keep us level.

I have a few baller developers on my team which can speak to the nuance of the macro constraints with Confiforms. We can file a ticket with Adaptavist to engage in a discussion.

[Nic Brough -Adaptavist-]

Macros provided by apps don't usually live in the database.