Jump to content


Stream Spec problems - Need help


  • Please log in to reply
4 replies to this topic

#1 LeFxGuy

LeFxGuy

    Member

  • Members
  • PipPip
  • 14 posts

Posted 08 May 2019 - 05:00 PM

Hey guys,

We are not sure what exactly happened but this is the problem:

Server version: 2016.2

1) A few days ago, we started checking into DTG and job specs etc. and triggers etc.  and we created a template workpsace/client spec (this could/should all be unrelated) + today we added our yearly serial number. We configured the custom spec = 1 to be able to edit jobspec
2) Today, we noticed that every stream definition (displayed in p4v) was truncated, so "import X/... //Y/..."  became "import X/...". In our stream spec, it said "path 2, remap 2 and ignored 2 when doing a "p4 spec stream"
3) Now, after closing the text file without any change, this is now a custom stream spec. This can be deleted with p4 spec -d stream.
4) When deleting this spec, we are now able to set correct import with 3 words, as in "import X/... //Y/..." for every stream definition via p4v
5) whenever we type "p4 spec stream", we get a "bad" template file presented and when closing the file/saving, we are back to fucked up imports

Question 1

Why do we get a bad template file for the stream spec from the server, although when deleting this "custom spec", the server operates correctly? How does the server standard stream spec look like?
What can affect/cause this behaviour?


Question 2)

Now, all stream definitions are bad/fucked. How can we restore this?  We got a checkpoint (although quite old...other topic *damn) and of course the journal. But we did not have a spec depot since today....
Any ideas?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 800 posts

Posted 08 May 2019 - 05:33 PM

First: "p4 spec" is not a supported command and in some cases can really badly break you.  I advise against messing with it unless you're willing to dedicate some serious time to testing your changes and possibly supporting them with form triggers.  "p4 jobspec" is a special case that IS explicitly supported (by virtue of jobs having dedicated database tables that store and index all the values of whatever fields you define in your jobspec) and I don't think you should need to enable any weird configurables to use it.

View PostLeFxGuy, on 08 May 2019 - 05:00 PM, said:

Why do we get a bad template file for the stream spec from the server, although when deleting this "custom spec", the server operates correctly? How does the server standard stream spec look like?
What can affect/cause this behaviour?

IIRC "import" paths with a depot component are some kind of weird hack that circumvent the normal spec parsing logic, since the spec definition language doesn't have a way to specify "two OR three words".  I didn't know that defining a custom stream spec broke this but it's not completely surprising.  (Although the more I think about this and stir the really old neurons up, the more it sounds like it might be something I discovered once upon a time and said "uggggggh" because it was a blocker for something else I was trying to do.  It was probably on my backlog to fix at some point.)

Are you 100% positive that all the streams are actually messed up, once you've deleted the custom spec?  P4V might be fooled by the custom spec into thinking that all those fields only have 2 words in them, but just editing the spec def shouldn't automatically go and rewrite all the actual view entries for all the streams, so their data should still be there underneath (and will be visible once the specdef is fixed).  The only way you'd actually mess up the streams AFAIK would be if you modified the specdef and THEN went and edited/re-saved all of the streams.

Quote

Now, all stream definitions are bad/fucked. How can we restore this?

Just get the old version from your spec depot!

Quote

But we did not have a spec depot since today....

...oh.

Maybe use your checkpoint/journal to replay the server back to a "good" state?  The journal file is a chronological record of database changes, so if you can find the right point in time to truncate it (obviously, do this with a copy, don't just start deleting parts of your one and only backup file) you can do a restore to that point in time, bring up a "back-in-time" version of the server, and query it for the good versions of the streams.

But again, before you start doing that, delete your custom specdef (and maybe unset that sketchy configurable) and double check that your streams aren't already exactly the way you left them.

#3 LeFxGuy

LeFxGuy

    Member

  • Members
  • PipPip
  • 14 posts

Posted 08 May 2019 - 08:05 PM

View PostSambwise, on 08 May 2019 - 05:33 PM, said:

IIRC "import" paths with a depot component are some kind of weird hack that circumvent the normal spec parsing logic, since the spec definition language doesn't have a way to specify "two OR three words".  

Well, to be more specific, we are ofc using stream depots and I think using the import keyword to share data is an approved way of working
https://www.perforce...eams.views.html

Good point with the stream views not being touched until we edit/resave them.  Gotta check this again.

But well, ok, We were already thinking about using the journal and copying the stream views out etc. But I guess we are in quite the mess. Fortunately, after this, we know about the spec depot :D and are more secure than before :D

#4 LeFxGuy

LeFxGuy

    Member

  • Members
  • PipPip
  • 14 posts

Posted 08 May 2019 - 08:08 PM

View PostSambwise, on 08 May 2019 - 05:33 PM, said:

The only way you'd actually mess up the streams AFAIK would be if you modified the specdef and THEN went and edited/re-saved all of the streams.


Oh yes, I guess we got out of this mess pretty unscathed...Thanks for mentioning this, makes us sleep better!

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 800 posts

Posted 08 May 2019 - 10:45 PM

View PostLeFxGuy, on 08 May 2019 - 08:05 PM, said:

Well, to be more specific, we are ofc using stream depots and I think using the import keyword to share data is an approved way of working
https://www.perforce...eams.views.html

Oh yes -- I mean it's a hack within the actual implementation of streams inside p4d, such that it's impossible to define a valid stream spec that supports "import" paths with their variable word counts and so at some point there's some kind of circumvention of the default spec parsing logic -- but if you define a custom spec, that probably kicks in first and messes things up.

Glad to hear no harm was done to the underlying stream data!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users